Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Mar 2018 16:34:13 -0700
From: Linus Torvalds <>
To: Kees Cook <>
Cc: Andrew Morton <>, Josh Poimboeuf <>, 
	Rasmus Villemoes <>, Randy Dunlap <>, 
	Miguel Ojeda <>, Ingo Molnar <>, 
	David Laight <>, Ian Abbott <>, 
	linux-input <>, linux-btrfs <>, 
	Network Development <>, 
	Linux Kernel Mailing List <>, 
	Kernel Hardening <>
Subject: Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 3:46 PM, Kees Cook <> wrote:
> So, AIUI, I can either get strict type checking, in which case, this
> is rejected (which I assume there is still a desire to have):
> int foo[const_max(6, sizeof(whatever))];

Ehh, yes, that looks fairly sane, and erroring out would be annoying.

But maybe we should just make the type explicit, and make it "const_max_t()"?

I think all the existing users are of type "max_t()" anyway due to the
very same issue, no?

At least if there's an explicit type like 'size_t', then passing in
"-1" becoming a large unsigned integer is understandable and clear,
not just some odd silent behavior.

Put another way: I think it's unacceptable that


magically becomes a huge positive number like in that patch of yours, but

     const_max_t(size_t, -1, 6)

*obviously* is a huge positive number.

The two things would *do* the same thing, but in the second case the
type is explicit and visible.

> due to __builtin_types_compatible_p() rejecting it, or I can construct
> a "positive arguments only" test, in which the above is accepted, but
> this is rejected:

That sounds acceptable too, although the "const_max_t()" thing is
presumably going to be simpler?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.