From: Kees Cook <keescook@chromium.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
Steven Rostedt <rostedt@goodmis.org>, Chris Mason <clm@fb.com>,
Josef Bacik <jbacik@fb.com>, David Sterba <dsterba@suse.com>,
"David S. Miller" <davem@davemloft.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Borislav Petkov <bp@suse.de>,
Randy Dunlap <rdunlap@infradead.org>,
Ian Abbott <abbotti@mev.co.uk>, "Tobin C. Harding" <me@tobin.cc>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Petr Mladek <pmladek@suse.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
Linux Btrfs <linux-btrfs@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH 0/3] Remove accidental VLA usage
Date: Thu, 8 Mar 2018 15:33:21 -0800 [thread overview]
Message-ID: <CAGXu5jLqwTpO+QECYvr33G5sp-j_m_MgTN0k+3Z9M2B14zUe-g@mail.gmail.com> (raw)
In-Reply-To: <CAKwiHFhmc7FybX4pUg+Ozd6TC_W5BWtf-ztGUObZKW=BWgfi2A@mail.gmail.com>
On Thu, Mar 8, 2018 at 2:12 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> On 8 March 2018 at 21:39, Kees Cook <keescook@chromium.org> wrote:
>> However, this works for me:
>>
>> #define __new_max(t1, t2, max1, max2, x, y) \
>> __builtin_choose_expr(__builtin_constant_p(x) && \
>> __builtin_constant_p(y) && \
>> __builtin_types_compatible_p(t1, t2), \
>> (t1)(x) > (t2)(y) ? (t1)(x) : (t2)(y), \
>> __max(t1, t2, max1, max2, x, y))
>>
>> #define new_max(x, y) \
>> __new_max(typeof(x), typeof(y), \
>> __UNIQUE_ID(max1_), __UNIQUE_ID(max2_), \
>> x, y)
>
> Yes, that would seem to do the trick.
>
> Thinking out loud: do we really want or need the
> __builtin_types_compatible condition when x and y are compile-time
> constants? I think it would be nice to be able to use max(16,
> sizeof(bla)) without having to cast either the literal or the sizeof.
> Just omitting the type compatibility check might be dangerous, but
> perhaps it could be relaxed to a check that both values are
> representable in their common promoted type. Something like
>
> (type_signed(t1) == type_signed(t2)) || ((t1)x >= 0 && (t2)y >= 0)
>
> should be safe (if the types have same signedness, or the value of
> signed type is positive), though it doesn't allow a few corner cases
> (e.g. short vs. unsigned char is always ok due to promotion to int,
> and also if the signed type is strictly wider than the unsigned type).
I agree, it would be nice. However, I think it'd be better to continue
to depend on max_t() for these kinds of cases though. For example:
char foo[max_t(size_t, 6, sizeof(something))];
Works with the proposed patch.
Also, I think this mismatch would already be triggering warnings, so
we shouldn't have any currently.
-Kees
--
Kees Cook
Pixel Security
next prev parent reply other threads:[~2018-03-08 23:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-08 3:30 [PATCH 0/3] Remove accidental VLA usage Kees Cook
2018-03-08 3:30 ` [PATCH v2 1/3] vsprintf: " Kees Cook
2018-03-08 8:25 ` Rasmus Villemoes
2018-03-08 11:21 ` Thomas Gleixner
2018-03-08 3:30 ` [PATCH 2/3] net: Remove accidental VLAs from proc buffers Kees Cook
2018-03-08 3:30 ` [PATCH 3/3] btrfs: tree-checker: Avoid accidental stack VLA Kees Cook
2018-03-08 11:33 ` David Sterba
2018-03-08 15:02 ` [PATCH 0/3] Remove accidental VLA usage Josh Poimboeuf
2018-03-08 18:02 ` Kees Cook
2018-03-08 18:11 ` Josh Poimboeuf
2018-03-08 18:06 ` Steven Rostedt
2018-03-08 19:57 ` Rasmus Villemoes
2018-03-08 20:39 ` Kees Cook
2018-03-08 22:12 ` Rasmus Villemoes
2018-03-08 23:33 ` Kees Cook [this message]
2018-03-08 20:49 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGXu5jLqwTpO+QECYvr33G5sp-j_m_MgTN0k+3Z9M2B14zUe-g@mail.gmail.com \
--to=keescook@chromium.org \
--cc=abbotti@mev.co.uk \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bp@suse.de \
--cc=clm@fb.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dsterba@suse.com \
--cc=gustavo@embeddedor.com \
--cc=jbacik@fb.com \
--cc=jpoimboe@redhat.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=me@tobin.cc \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pantelis.antoniou@konsulko.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=tglx@linutronix.de \
--cc=yamada.masahiro@socionext.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).