From: Alejandro Colomar <alx@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
corbet@lwn.net, serge@hallyn.com,
Martin Uecker <uecker@tugraz.at>,
linux-mm@kvack.org
Subject: Re: kalloc_objs() may not be as safe as it seems
Date: Thu, 19 Mar 2026 22:18:44 +0100 [thread overview]
Message-ID: <abxmpctCj-E690An@devuan> (raw)
In-Reply-To: <202603191308.ED08BC65B2@keescook>
[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]
Hi Kees,
On 2026-03-19T13:12:41-0700, Kees Cook wrote:
> On Wed, Mar 18, 2026 at 05:33:35PM +0100, Alejandro Colomar wrote:
> > [...]
> > After sleeping, I had some idea.
> >
> > We could have coccinelle add typeof() around the first parameter when
> > it's an expression (not a type). Then, we could enforce that the first
> > parameter is a type name.
> >
> > That is:
> >
> > p = kmalloc_objs(int, 42); // ok
> > -q = kmalloc_objs(*p, 7);
> > +q = kmalloc_objs(typeof(*p), 7);
> >
> > I expect this would be doable with coccinelle.
> >
> > Then, new code would be required to pass a type name. And people could
> > slowly replace the existing typeof() calls at their own pace.
> >
> > What do you think?
>
> Well, it'd serve as a visual indicator, but it's redundant (typeof() is
> already used internally).
It is redundant now. But my idea would be two steps:
1) Add the redundant typeof() in the first parameter, when it's not a
type already.
2) Change the kmalloc_objs() implementation so that it doesn't do
typeof() internally. This would make step 1 non-redundant.
> Given it would only be a potential for
> confusion on integral types, I'm less convinced this needs solving.
It's directly adding safety for integral types only, yes.
But it's also improving readability. There's no precedent of macros
that take a variable just for its type, and it feels a bit awkward to
read the current one. By doing typeof(), people can relate better why
it takes that parameter.
If I read "q = kmalloc_objs(*q, 7)", the first thing I wonder is: why is
this macro reading *q?? If I read "q = kmalloc_objs(typeof(*p), 7)",
then all's fine in my brain.
> For completeness, though, this Coccinelle script:
>
> // Options: --include-headers-for-types --all-includes --include-headers --keep-comments
> virtual patch
>
> @type_not_var depends on patch@
> type TYPE;
> TYPE *VAR;
> identifier ALLOC =
> {kmalloc_obj,kzalloc_obj,kmalloc_objs,kzalloc_objs,kmalloc_flex,kzalloc_flex};
> @@
>
> VAR = ALLOC(
> - *VAR
> + TYPE
> , ...)
>
> Produces:
>
> 6007 files changed, 12430 insertions(+), 11767 deletions(-)
>
> Which is a lot of churn...
Yeah, it would be a lot of churn if we were at rest. But since the dust
has not yet settled, it might be doable.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2026-03-19 21:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <abhGS0n_RsUG97Ni@devuan>
[not found] ` <202603171402.B2BD1B1@keescook>
[not found] ` <abnGea5Qwp3VYDda@devuan>
[not found] ` <abrRMnxzCKEuhnrS@devuan>
2026-03-19 20:12 ` kalloc_objs() may not be as safe as it seems Kees Cook
2026-03-19 21:18 ` Alejandro Colomar [this message]
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=abxmpctCj-E690An@devuan \
--to=alx@kernel.org \
--cc=corbet@lwn.net \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=serge@hallyn.com \
--cc=uecker@tugraz.at \
/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