From: Kees Cook
> Sent: 13 March 2018 22:15
...
> I'll send a "const_max()" which will refuse to work on
> non-constant-values (so it doesn't get accidentally used on variables
> that could be exposed to double-evaluation), and will work for stack
> array declarations (to avoid the
From: Kees Cook
> Sent: 13 March 2018 22:15
...
> I'll send a "const_max()" which will refuse to work on
> non-constant-values (so it doesn't get accidentally used on variables
> that could be exposed to double-evaluation), and will work for stack
> array declarations (to avoid the
On Tue, Mar 13, 2018 at 2:02 PM, Andrew Morton
wrote:
> On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote:
>
>> On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
>> wrote:
>> > On Mon, Mar 12, 2018 at 3:55 PM,
On Tue, Mar 13, 2018 at 2:02 PM, Andrew Morton
wrote:
> On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote:
>
>> On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
>> wrote:
>> > On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
>> > wrote:
>> >>
>> >> Replacing the __builtin_choose_expr() with ?:
On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote:
> On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
> wrote:
> > On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
> > wrote:
> >>
> >> Replacing the
On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote:
> On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
> wrote:
> > On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
> > wrote:
> >>
> >> Replacing the __builtin_choose_expr() with ?: works of course.
> >
> > Hmm. That sounds like the right thing to
The amount of replicated defined could also be reduced by passing > or <
to a min_max() macro.
So you start off with something like:
#define min(x, y) __min_max(x, <, y)
#define max(x, y) __min_max(x, >, y)
then have:
#define __min_max(x, cond, y) ((x) cond (y) ? (x) : (y))
in all its associated
The amount of replicated defined could also be reduced by passing > or <
to a min_max() macro.
So you start off with something like:
#define min(x, y) __min_max(x, <, y)
#define max(x, y) __min_max(x, >, y)
then have:
#define __min_max(x, cond, y) ((x) cond (y) ? (x) : (y))
in all its associated
On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
wrote:
> On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
> wrote:
>>
>> Replacing the __builtin_choose_expr() with ?: works of course.
>
> Hmm. That sounds like the right thing to do. We were
On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
wrote:
> On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
> wrote:
>>
>> Replacing the __builtin_choose_expr() with ?: works of course.
>
> Hmm. That sounds like the right thing to do. We were so myopically
> staring at the __builtin_choose_expr()
On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
wrote:
>
> Replacing the __builtin_choose_expr() with ?: works of course.
Hmm. That sounds like the right thing to do. We were so myopically
staring at the __builtin_choose_expr() problem that we overlooked the
obvious
On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
wrote:
>
> Replacing the __builtin_choose_expr() with ?: works of course.
Hmm. That sounds like the right thing to do. We were so myopically
staring at the __builtin_choose_expr() problem that we overlooked the
obvious solution.
Using
On Fri, 9 Mar 2018 17:30:15 -0800 Kees Cook wrote:
> > It's one reason why I wondered if simplifying the expression to have
> > just that single __builtin_constant_p() might not end up working..
>
> Yeah, it seems like it doesn't bail out as "false" for complex
>
On Fri, 9 Mar 2018 17:30:15 -0800 Kees Cook wrote:
> > It's one reason why I wondered if simplifying the expression to have
> > just that single __builtin_constant_p() might not end up working..
>
> Yeah, it seems like it doesn't bail out as "false" for complex
> expressions given to
On Fri, Mar 09, 2018 at 01:10:30PM -0800, Linus Torvalds wrote:
> On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote:
> > When max() is used in stack array size calculations from literal values
> > (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
> >
On Fri, Mar 09, 2018 at 01:10:30PM -0800, Linus Torvalds wrote:
> On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote:
> > When max() is used in stack array size calculations from literal values
> > (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
> > thinks this is a dynamic
On Sun, Mar 11, 2018 at 4:05 AM, Ingo Molnar wrote:
>
> BTW., while I fully agree with everything you said, it's not entirely correct
> to
> claim that if a C compiler can generate VLA code it is necessarily able to
> parse
> and evaluate constant array sizes "just fine".
>
>
On Sun, Mar 11, 2018 at 4:05 AM, Ingo Molnar wrote:
>
> BTW., while I fully agree with everything you said, it's not entirely correct
> to
> claim that if a C compiler can generate VLA code it is necessarily able to
> parse
> and evaluate constant array sizes "just fine".
>
> Constant
* Linus Torvalds wrote:
> So an error message like
>
>warning: ISO C90 requires array sizes to be constant-expressions
>
> would be technically correct and useful from a portability angle. It
> tells you when you're doing something non-portable, and should
* Linus Torvalds wrote:
> So an error message like
>
>warning: ISO C90 requires array sizes to be constant-expressions
>
> would be technically correct and useful from a portability angle. It
> tells you when you're doing something non-portable, and should be
> automatically enabled with
On Sat, Mar 10, 2018 at 6:51 PM, Linus Torvalds
wrote:
>
> So in *historical* context - when a compiler didn't do variable length
> arrays at all - the original semantics of C "constant expressions"
> actually make a ton of sense.
>
> You can basically think of a
On Sat, Mar 10, 2018 at 6:51 PM, Linus Torvalds
wrote:
>
> So in *historical* context - when a compiler didn't do variable length
> arrays at all - the original semantics of C "constant expressions"
> actually make a ton of sense.
>
> You can basically think of a constant expression as something
On Sat, Mar 10, 2018 at 9:34 AM, Miguel Ojeda
wrote:
>
> So the warning is probably implemented to just trigger whenever VLAs
> are used but the given standard does not allow them, for all
> languages. The problem is why the ISO C90 frontend is not giving an
>
On Sat, Mar 10, 2018 at 9:34 AM, Miguel Ojeda
wrote:
>
> So the warning is probably implemented to just trigger whenever VLAs
> are used but the given standard does not allow them, for all
> languages. The problem is why the ISO C90 frontend is not giving an
> error for using invalid syntax for
On Sat, Mar 10, 2018 at 5:30 PM, Linus Torvalds
wrote:
> On Sat, Mar 10, 2018 at 7:33 AM, Kees Cook wrote:
>>
>> Alright, I'm giving up on fixing max(). I'll go back to STACK_MAX() or
>> some other name for the simple macro. Bleh.
>
> Oh, and
On Sat, Mar 10, 2018 at 5:30 PM, Linus Torvalds
wrote:
> On Sat, Mar 10, 2018 at 7:33 AM, Kees Cook wrote:
>>
>> Alright, I'm giving up on fixing max(). I'll go back to STACK_MAX() or
>> some other name for the simple macro. Bleh.
>
> Oh, and I'm starting to see the real problem.
>
> It's not
On Sat, Mar 10, 2018 at 7:33 AM, Kees Cook wrote:
>
> Alright, I'm giving up on fixing max(). I'll go back to STACK_MAX() or
> some other name for the simple macro. Bleh.
Oh, and I'm starting to see the real problem.
It's not that our current "min/max()" are broiken. It's
On Sat, Mar 10, 2018 at 7:33 AM, Kees Cook wrote:
>
> Alright, I'm giving up on fixing max(). I'll go back to STACK_MAX() or
> some other name for the simple macro. Bleh.
Oh, and I'm starting to see the real problem.
It's not that our current "min/max()" are broiken. It's that "-Wvla" is
On Sat, Mar 10, 2018 at 7:33 AM, Kees Cook wrote:
>
> And sparse freaks out too:
>
>drivers/net/ethernet/via/via-velocity.c:97:26: sparse: incorrect
> type in initializer (different address spaces) @@expected void
> *addr @@got struct mac_regs [noderef]
On Sat, Mar 10, 2018 at 7:33 AM, Kees Cook wrote:
>
> And sparse freaks out too:
>
>drivers/net/ethernet/via/via-velocity.c:97:26: sparse: incorrect
> type in initializer (different address spaces) @@expected void
> *addr @@got struct mac_regs [noderef]
On Fri, Mar 9, 2018 at 11:03 PM, Miguel Ojeda
wrote:
>
> Just compiled 4.9.0 and it seems to work -- so that would be the
> minimum required.
>
> Sigh...
>
> Some enterprise distros are either already shipping gcc >= 5 or will
> probably be shipping it soon (e.g.
On Fri, Mar 9, 2018 at 11:03 PM, Miguel Ojeda
wrote:
>
> Just compiled 4.9.0 and it seems to work -- so that would be the
> minimum required.
>
> Sigh...
>
> Some enterprise distros are either already shipping gcc >= 5 or will
> probably be shipping it soon (e.g. RHEL 8), so how much does it hurt
On Fri, Mar 9, 2018 at 10:10 PM, Miguel Ojeda
wrote:
> On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote:
>> On 03/09/2018 04:07 PM, Andrew Morton wrote:
>>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>>>
On Fri, Mar 9, 2018 at 10:10 PM, Miguel Ojeda
wrote:
> On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote:
>> On 03/09/2018 04:07 PM, Andrew Morton wrote:
>>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>>>
When max() is used in stack array size calculations from literal values
On Sat, Mar 10, 2018 at 7:10 AM, Miguel Ojeda
wrote:
> On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote:
>> On 03/09/2018 04:07 PM, Andrew Morton wrote:
>>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>>>
On Sat, Mar 10, 2018 at 7:10 AM, Miguel Ojeda
wrote:
> On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote:
>> On 03/09/2018 04:07 PM, Andrew Morton wrote:
>>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>>>
When max() is used in stack array size calculations from literal values
On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote:
> On 03/09/2018 04:07 PM, Andrew Morton wrote:
>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>>
>>> When max() is used in stack array size calculations from literal values
>>> (e.g. "char
On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote:
> On 03/09/2018 04:07 PM, Andrew Morton wrote:
>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>>
>>> When max() is used in stack array size calculations from literal values
>>> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]",
On 03/09/2018 04:07 PM, Andrew Morton wrote:
> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>
>> When max() is used in stack array size calculations from literal values
>> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
>> thinks this is a
On 03/09/2018 04:07 PM, Andrew Morton wrote:
> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>
>> When max() is used in stack array size calculations from literal values
>> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
>> thinks this is a dynamic calculation due to
On Fri, Mar 9, 2018 at 5:31 PM, Kees Cook wrote:
>
> WTF, gmail just blasted HTML into my explicitly plain-text email?!
> Apologies...
There's more now in your email, I think maybe it's triggered by your
signature file and some gmail web interface bug. Or it just tries to
On Fri, Mar 9, 2018 at 5:31 PM, Kees Cook wrote:
>
> WTF, gmail just blasted HTML into my explicitly plain-text email?!
> Apologies...
There's more now in your email, I think maybe it's triggered by your
signature file and some gmail web interface bug. Or it just tries to
force quote using
On Fri, Mar 9, 2018 at 5:30 PM, Kees Cook wrote:
> --
> Kees Cook
> Pixel SecurityOn
> [...]
WTF, gmail just blasted HTML into my explicitly plain-text email?! Apologies...
--
Kees Cook
Pixel SecurityOn
Fri, Mar 9, 2018 at 5:30 PM, Kees Cook mailto:keesc...@chromium.org;
On Fri, Mar 9, 2018 at 5:30 PM, Kees Cook wrote:
> --
> Kees Cook
> Pixel SecurityOn
> [...]
WTF, gmail just blasted HTML into my explicitly plain-text email?! Apologies...
--
Kees Cook
Pixel SecurityOn
Fri, Mar 9, 2018 at 5:30 PM, Kees Cook mailto:keesc...@chromium.org;
On Fri, Mar 9, 2018 at 4:38 PM, Linus Torvalds
wrote:
> On Fri, Mar 9, 2018 at 4:32 PM, Andrew Morton
> wrote:
>>
>> I wonder which gcc versions actually accept Kees's addition.
Ah, my old nemesis, gcc 4.4.4. *sob*
> Note that we
On Fri, Mar 9, 2018 at 4:38 PM, Linus Torvalds
wrote:
> On Fri, Mar 9, 2018 at 4:32 PM, Andrew Morton
> wrote:
>>
>> I wonder which gcc versions actually accept Kees's addition.
Ah, my old nemesis, gcc 4.4.4. *sob*
> Note that we already do have this pattern, as seen by:
>
> git grep -2
On Fri, Mar 9, 2018 at 4:32 PM, Andrew Morton wrote:
>
> I wonder which gcc versions actually accept Kees's addition.
Note that we already do have this pattern, as seen by:
git grep -2 __builtin_choose_expr | grep -2 __builtin_constant_p
which show
On Fri, Mar 9, 2018 at 4:32 PM, Andrew Morton wrote:
>
> I wonder which gcc versions actually accept Kees's addition.
Note that we already do have this pattern, as seen by:
git grep -2 __builtin_choose_expr | grep -2 __builtin_constant_p
which show drivers/pinctrl/intel/pinctrl-intel.h, so
On Fri, 9 Mar 2018 16:28:51 -0800 Linus Torvalds
wrote:
> On Fri, Mar 9, 2018 at 4:07 PM, Andrew Morton
> wrote:
> >
> > A brief poke failed to reveal a workaround - gcc-4.4.4 doesn't appear
> > to know that __builtin_constant_p(x) is
On Fri, 9 Mar 2018 16:28:51 -0800 Linus Torvalds
wrote:
> On Fri, Mar 9, 2018 at 4:07 PM, Andrew Morton
> wrote:
> >
> > A brief poke failed to reveal a workaround - gcc-4.4.4 doesn't appear
> > to know that __builtin_constant_p(x) is a constant. Or something.
>
> LOL.
>
> I suspect it
On Fri, Mar 9, 2018 at 4:07 PM, Andrew Morton wrote:
>
> A brief poke failed to reveal a workaround - gcc-4.4.4 doesn't appear
> to know that __builtin_constant_p(x) is a constant. Or something.
LOL.
I suspect it might be that it wants to evaluate
On Fri, Mar 9, 2018 at 4:07 PM, Andrew Morton wrote:
>
> A brief poke failed to reveal a workaround - gcc-4.4.4 doesn't appear
> to know that __builtin_constant_p(x) is a constant. Or something.
LOL.
I suspect it might be that it wants to evaluate
__builtin_choose_expr() at an earlier stage
On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
> When max() is used in stack array size calculations from literal values
> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
> thinks this is a dynamic calculation due to the single-eval logic, which
>
On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
> When max() is used in stack array size calculations from literal values
> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
> thinks this is a dynamic calculation due to the single-eval logic, which
> is not needed in the
On Fri, Mar 9, 2018 at 1:10 PM, Linus Torvalds
wrote:
> On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote:
>> When max() is used in stack array size calculations from literal values
>> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]",
On Fri, Mar 9, 2018 at 1:10 PM, Linus Torvalds
wrote:
> On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote:
>> When max() is used in stack array size calculations from literal values
>> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
>> thinks this is a dynamic calculation
On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote:
> When max() is used in stack array size calculations from literal values
> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
> thinks this is a dynamic calculation due to the single-eval logic, which
>
On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote:
> When max() is used in stack array size calculations from literal values
> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
> thinks this is a dynamic calculation due to the single-eval logic, which
> is not needed in the
When max() is used in stack array size calculations from literal values
(e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
thinks this is a dynamic calculation due to the single-eval logic, which
is not needed in the literal case. This change removes several accidental
stack
When max() is used in stack array size calculations from literal values
(e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
thinks this is a dynamic calculation due to the single-eval logic, which
is not needed in the literal case. This change removes several accidental
stack
60 matches
Mail list logo