[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1a9a927f94cc4a8fa2d5de8c660f6d09@AcuMS.aculab.com>
Date: Thu, 8 Jun 2023 16:25:41 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Linus Torvalds' <torvalds@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>
CC: Peter Zijlstra <peterz@...radead.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ojeda@...nel.org" <ojeda@...nel.org>,
"ndesaulniers@...gle.com" <ndesaulniers@...gle.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"will@...nel.org" <will@...nel.org>,
"longman@...hat.com" <longman@...hat.com>,
"boqun.feng@...il.com" <boqun.feng@...il.com>,
"juri.lelli@...hat.com" <juri.lelli@...hat.com>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"dietmar.eggemann@....com" <dietmar.eggemann@....com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"bsegall@...gle.com" <bsegall@...gle.com>,
"mgorman@...e.de" <mgorman@...e.de>,
"bristot@...hat.com" <bristot@...hat.com>,
"vschneid@...hat.com" <vschneid@...hat.com>,
"paulmck@...nel.org" <paulmck@...nel.org>,
"frederic@...nel.org" <frederic@...nel.org>,
"quic_neeraju@...cinc.com" <quic_neeraju@...cinc.com>,
"joel@...lfernandes.org" <joel@...lfernandes.org>,
"josh@...htriplett.org" <josh@...htriplett.org>,
"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
"jiangshanlai@...il.com" <jiangshanlai@...il.com>,
"rcu@...r.kernel.org" <rcu@...r.kernel.org>,
"tj@...nel.org" <tj@...nel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"linux-toolchains@...r.kernel.org" <linux-toolchains@...r.kernel.org>
Subject: RE: [PATCH v2 0/2] Lock and Pointer guards
From: Linus Torvalds
> Sent: 06 June 2023 16:46
>
> On Tue, Jun 6, 2023 at 8:31 AM Kees Cook <keescook@...omium.org> wrote:
> >
> > nit: Linus's example was "(void *)8" (instead of 1) because we've had
> > issues in the past with alignment warnings on archs that are sensitive
> > to it. (e.g. see the __is_constexpr() macro which is doing NULL/!NULL
> > comparisons.)
__is_constexpr() is playing entirely different games.
Basically the type of (x ? (void *)y : (int *)z)
depends on whether 'y' is a compile-time 0 (int *) or not (void *).
...
> So I'm not sure the 1-vs-8 actually matters. We do other things that
> assume that low bits in a pointer are retained and valid, even if in
> theory the C type system might have issues with it.
Yes, given that gcc will assume a pointer is aligned if you try
to memcpy() from it, I'm surprised it doesn't always assume that.
In which case (long)ptr_to_int & 3 can be validly assumed to be zero.
I've found some 'day job' code that passed the address of a
member of a 'packed' structure to a function which then used
host ordered unsigned char[] accesses.
The compiler is certainly allowed to convert that back to
a word write - which would then fault.
(I've not looked to see if any modern compilers do.)
Of course the simple ptr->member would have be fine.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists