From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Kees Cook <keescook@chromium.org>,
Daniel Vetter <daniel.vetter@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Julia Lawall <julia.lawall@lip6.fr>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <mawilcox@microsoft.com>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
cocci@systeme.lip6.fr, Himanshu Jha <himanshujha199640@gmail.com>
Subject: Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct
Date: Fri, 4 May 2018 01:00:43 +0200 [thread overview]
Message-ID: <4e25ff5b-f8fc-7012-83c2-b56e6928e8bc@rasmusvillemoes.dk> (raw)
In-Reply-To: <CAGXu5j+tYhQOfVMkZdPzW5CX103LHpm8SYSN51VFLufn0Z0y6Q@mail.gmail.com>
On 2018-05-01 19:00, Kees Cook wrote:
> On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>>
>> gcc 5.1+ (I think) have the __builtin_OP_overflow checks that should
>> generate reasonable code. Too bad there's no completely generic
>> check_all_ops_in_this_expression(a+b*c+d/e, or_jump_here). Though it's
>> hard to define what they should be checked against - probably would
>> require all subexpressions (including the variables themselves) to have
>> the same type.
>>
>> plug: https://lkml.org/lkml/2015/7/19/358
>
> That's a very nice series. Why did it never get taken?
Well, nobody seemed particularly interested, and then
https://lkml.org/lkml/2015/10/28/215 happened... but he did later seem
to admit that it could be useful for the multiplication checking, and
that "the gcc interface for multiplication overflow is fine".
I still think even for unsigned types overflow checking can be subtle. E.g.
u32 somevar;
if (somevar + sizeof(foo) < somevar)
return -EOVERFLOW;
somevar += sizeof(this);
is broken, because the LHS is promoted to unsigned long/size_t, then so
is the RHS for the comparison, and the comparison is thus always false
(on 64bit). It gets worse if the two types are more "opaque", and in any
case it's not always easy to verify at a glance that the types are the
same, or at least that the expression of the widest type is on the RHS.
> It seems to do the right things quite correctly.
Yes, I wouldn't suggest it without the test module verifying corner
cases, and checking it has the same semantics whether used with old or
new gcc.
Would you shepherd it through if I updated the patches and resent?
Rasmus
next prev parent reply other threads:[~2018-05-03 23:00 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-14 18:26 [PATCH 0/2] Add kvzalloc_struct to complement kvzalloc_array Matthew Wilcox
2018-02-14 18:26 ` [PATCH 1/2] mm: Add kernel-doc for kvfree Matthew Wilcox
2018-02-14 18:26 ` [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct Matthew Wilcox
2018-02-14 19:22 ` Kees Cook
2018-02-14 19:27 ` Julia Lawall
2018-02-14 19:35 ` Matthew Wilcox
2018-03-07 21:18 ` Julia Lawall
2018-03-08 2:58 ` Matthew Wilcox
2018-03-08 6:24 ` Julia Lawall
2018-03-08 23:05 ` Matthew Wilcox
2018-03-09 5:59 ` Julia Lawall
2018-03-13 17:19 ` Julia Lawall
2018-03-13 18:32 ` Matthew Wilcox
2018-03-13 18:35 ` Julia Lawall
2018-04-29 16:59 ` Kees Cook
2018-04-29 20:30 ` Matthew Wilcox
2018-04-30 19:02 ` Kees Cook
2018-04-30 20:16 ` Matthew Wilcox
2018-04-30 21:29 ` Rasmus Villemoes
2018-04-30 22:41 ` Matthew Wilcox
2018-05-01 17:00 ` Kees Cook
2018-05-01 17:41 ` Julia Lawall
2018-05-03 23:00 ` Rasmus Villemoes [this message]
2018-05-04 0:36 ` Kees Cook
2018-05-04 0:40 ` Kees Cook
2018-04-30 22:29 ` Kees Cook
2018-02-14 19:55 ` Christopher Lameter
2018-02-14 20:14 ` Matthew Wilcox
2018-02-15 15:55 ` Christopher Lameter
2018-02-15 16:23 ` Matthew Wilcox
2018-02-15 17:06 ` Christopher Lameter
2018-02-22 1:28 ` Kees Cook
2018-05-04 7:42 ` Linus Torvalds
2018-05-04 13:14 ` Matthew Wilcox
2018-05-04 15:35 ` Linus Torvalds
2018-05-04 16:03 ` Kees Cook
2018-02-14 18:47 ` [PATCH 0/2] Add kvzalloc_struct to complement kvzalloc_array Joe Perches
2018-02-14 19:23 ` Kees Cook
2018-02-14 19:32 ` Joe Perches
2018-02-14 19:36 ` Matthew Wilcox
2018-02-14 19:43 ` Joe Perches
2018-02-14 19:56 ` Matthew Wilcox
2018-02-14 20:06 ` Joe Perches
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=4e25ff5b-f8fc-7012-83c2-b56e6928e8bc@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=akpm@linux-foundation.org \
--cc=cocci@systeme.lip6.fr \
--cc=daniel.vetter@intel.com \
--cc=himanshujha199640@gmail.com \
--cc=julia.lawall@lip6.fr \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mawilcox@microsoft.com \
--cc=willy@infradead.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