From: Peter Rosin <peda@axentia.se>
To: Kees Cook <keescook@chromium.org>
Cc: Matthew Wilcox <mawilcox@microsoft.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v3 00/16] Provide saturating helpers for allocation
Date: Fri, 1 Jun 2018 15:50:57 +0200 [thread overview]
Message-ID: <0634bebc-e16d-ed40-ee26-5401e4bc7b50@axentia.se> (raw)
In-Reply-To:
Kees Cook wrote:
> This is a stab at providing three new helpers for allocation size
> calculation:
>
> struct_size(), array_size(), and array3_size().
>
> These are implemented on top of Rasmus's overflow checking functions. The
> existing allocators are adjusted to use the more efficient overflow
> checks as well.
>
> While the tree-wide conversions continue to be largely unchanged,
> I've updated their commit logs a bit with some more details on
> rationale and options. Notably, while there are NO plans to replace
> kmalloc_array() and kcalloc() with kmalloc(array_size(...),...) and
> kzalloc(array_size(...),...), the treewide conversions only add the
> new helpers, as making the ..._array() and ...calloc() conversions
> balloons the Coccinelle script terribly (I haven't found a way to
> make the replacement function name depend on the matched regular expression).
> So, while nothing does:
> kmalloc_array(a, b, ...) -> kmalloc(array_size(a, b), ...)
> the treewide changes DO perform changes like this:
> kmalloc(a * b, ...) -> kmalloc(array_size(a, b), ...)
>
> It should also be noted that the treewide changes overlap with a few
> recently reported "real" overflows, so these aren't theoretical fixes.
>
> At the very least, I'd like to get the helpers and self-test landed in
> the v4.18 merge window (coming right up!) since those are relatively
> self-contained. If the treewide changes need adjustment we've got,
> in theory, through the end of -rc2 to land those.
In some places you make an effort to have the count as the first
argument, e.g. in "treewide: Use array_size() for kmalloc()-family"
- kbuf = kmalloc(sizeof(*kbuf) * maxevents, GFP_KERNEL);
+ kbuf = kmalloc(array_size(maxevents, sizeof(*kbuf)), GFP_KERNEL);
which is reordered, and from the same patch
- mapping->bitmaps = kzalloc(extensions * sizeof(unsigned long *),
- GFP_KERNEL);
+ mapping->bitmaps = kzalloc(array_size(extensions, sizeof(unsigned long *)),
+ GFP_KERNEL);
which is not reordered. That is all fine by me.
But then, in "treewide: Use array_size() for devm_*alloc()-like, leftovers"
this reordering thing is not happening, e.g.
values = devm_kzalloc(&pdev->dev,
- sizeof(*mux->data.values) * mux->data.n_values,
+ array_size(sizeof(*mux->data.values), mux->data.n_values),
GFP_KERNEL);
Also, the above shows two of numerous examples of the tools breaking the
80 column "rule", even though the surrounding code makes decent effort to
uphold it.
I can see why these things happen, but they are annoying.
Cheers,
Peter
next reply other threads:[~2018-06-01 13:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 13:50 Peter Rosin [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-06-01 0:42 Kees Cook
2018-06-01 0:54 ` Linus Torvalds
2018-06-01 4:18 ` Kees Cook
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=0634bebc-e16d-ed40-ee26-5401e4bc7b50@axentia.se \
--to=peda@axentia.se \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mawilcox@microsoft.com \
--cc=torvalds@linux-foundation.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