Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-20 Thread Kees Cook
On Tue, Jun 18, 2024 at 10:22:42AM +0200, Peter Zijlstra wrote: > On Mon, Jun 17, 2024 at 10:28:20AM -0700, Kees Cook wrote: > > > But, using type attributes we have much more flexibility. Hence, the > > proposed "wraps" attribute: > > https://github.com/llvm/llvm-project/pull/86618 > > So I stil

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-18 Thread Peter Zijlstra
On Mon, Jun 17, 2024 at 10:19:15AM -0700, Kees Cook wrote: > On Fri, Jun 14, 2024 at 12:17:08PM +0200, Peter Zijlstra wrote: > > On Wed, Jun 12, 2024 at 04:23:31PM -0700, Kees Cook wrote: > > > On Thu, Jun 13, 2024 at 12:08:21AM +0200, Peter Zijlstra wrote: > > > > On Wed, Jun 12, 2024 at 12:01:19P

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-18 Thread Peter Zijlstra
On Mon, Jun 17, 2024 at 10:28:20AM -0700, Kees Cook wrote: > But, using type attributes we have much more flexibility. Hence, the > proposed "wraps" attribute: > https://github.com/llvm/llvm-project/pull/86618 So I still think that's going about things backwards. unsigned explicitly wraps. signe

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-17 Thread Kees Cook
On Sat, Jun 15, 2024 at 06:09:07PM +0200, Martin Uecker wrote: > Am Freitag, dem 14.06.2024 um 12:17 +0200 schrieb Peter Zijlstra: > > On Wed, Jun 12, 2024 at 04:23:31PM -0700, Kees Cook wrote: > > > On Thu, Jun 13, 2024 at 12:08:21AM +0200, Peter Zijlstra wrote: > > > > On Wed, Jun 12, 2024 at 12:

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-17 Thread Kees Cook
On Fri, Jun 14, 2024 at 12:17:08PM +0200, Peter Zijlstra wrote: > On Wed, Jun 12, 2024 at 04:23:31PM -0700, Kees Cook wrote: > > On Thu, Jun 13, 2024 at 12:08:21AM +0200, Peter Zijlstra wrote: > > > On Wed, Jun 12, 2024 at 12:01:19PM -0700, Kees Cook wrote: > > > > I'm happy to take patches. And fo

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-15 Thread Martin Uecker
Am Freitag, dem 14.06.2024 um 12:17 +0200 schrieb Peter Zijlstra: > On Wed, Jun 12, 2024 at 04:23:31PM -0700, Kees Cook wrote: > > On Thu, Jun 13, 2024 at 12:08:21AM +0200, Peter Zijlstra wrote: > > > On Wed, Jun 12, 2024 at 12:01:19PM -0700, Kees Cook wrote: > > > > I'm happy to take patches. And

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-14 Thread Peter Zijlstra
On Wed, Jun 12, 2024 at 04:23:31PM -0700, Kees Cook wrote: > On Thu, Jun 13, 2024 at 12:08:21AM +0200, Peter Zijlstra wrote: > > On Wed, Jun 12, 2024 at 12:01:19PM -0700, Kees Cook wrote: > > > I'm happy to take patches. And for this bikeshed, this would be better > > > named under the size_*() hel

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-12 Thread Kees Cook
On Thu, Jun 13, 2024 at 12:08:21AM +0200, Peter Zijlstra wrote: > On Wed, Jun 12, 2024 at 12:01:19PM -0700, Kees Cook wrote: > > I'm happy to take patches. And for this bikeshed, this would be better > > named under the size_*() helpers which are trying to keep size_t > > calculations from overflow

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-12 Thread Peter Zijlstra
On Wed, Jun 12, 2024 at 12:01:19PM -0700, Kees Cook wrote: > On Tue, Jun 11, 2024 at 09:55:42AM +0200, Peter Zijlstra wrote: > > On Mon, Jun 10, 2024 at 02:46:09PM -0700, Kees Cook wrote: > > > > > > I really detest this thing because it makes what was trivially readable > > > > into something opa

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-12 Thread Kees Cook
On Tue, Jun 11, 2024 at 09:55:42AM +0200, Peter Zijlstra wrote: > On Mon, Jun 10, 2024 at 02:46:09PM -0700, Kees Cook wrote: > > > > I really detest this thing because it makes what was trivially readable > > > into something opaque. Get me that type qualifier that traps on overflow > > > and writ

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-11 Thread Peter Zijlstra
On Mon, Jun 10, 2024 at 02:46:09PM -0700, Kees Cook wrote: > > I really detest this thing because it makes what was trivially readable > > into something opaque. Get me that type qualifier that traps on overflow > > and write plain C. All this __builtin_overflow garbage is just that, > > unreadabl

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-10 Thread Kees Cook
On Mon, Jun 10, 2024 at 10:05:44PM +0200, Peter Zijlstra wrote: > On Mon, Jun 10, 2024 at 10:28:52AM -0700, Kees Cook wrote: > > On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote: > > > Hi everyone, > > > > > > This is an effort to get rid of all multiplications from allocation > > > fu

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-10 Thread Peter Zijlstra
On Mon, Jun 10, 2024 at 10:28:52AM -0700, Kees Cook wrote: > On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote: > > Hi everyone, > > > > This is an effort to get rid of all multiplications from allocation > > functions in order to prevent integer overflows [1][2]. > > I didn't actually

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-10 Thread Kees Cook
On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote: > Hi everyone, > > This is an effort to get rid of all multiplications from allocation > functions in order to prevent integer overflows [1][2]. I didn't actually see these 3 patches in this thread nor via lore. > In the first patch,

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-10 Thread Peter Zijlstra
On Sat, Jun 08, 2024 at 10:50:44AM +0200, Erick Archer wrote: > Hi Andrew, > > On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote: > > Hi everyone, > > > > This is an effort to get rid of all multiplications from allocation > > functions in order to prevent integer overflows [1][2]. > >

Re: [PATCH v4 0/3] Hardening perf subsystem

2024-06-08 Thread Erick Archer
Hi Andrew, On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote: > Hi everyone, > > This is an effort to get rid of all multiplications from allocation > functions in order to prevent integer overflows [1][2]. > > In the first patch, the "struct amd_uncore_ctx" can be refactored to > use

[PATCH v4 0/3] Hardening perf subsystem

2024-06-01 Thread Erick Archer
Hi everyone, This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. In the first patch, the "struct amd_uncore_ctx" can be refactored to use a flex array for the "events" member. This way, the allocation/ freeing of the memory c