Date:   Wed, 4 May 2022 08:38:13 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     "Gustavo A . R . Silva" <gustavoars@...nel.org>,
        Keith Packard <keithp@...thp.com>,
        Francis Laniel <laniel_francis@...vacyrequired.com>,
        Daniel Axtens <dja@...ens.net>,
        Dan Williams <dan.j.williams@...el.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Guenter Roeck <linux@...ck-us.net>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Tadeusz Struk <tadeusz.struk@...aro.org>,
        Alexei Starovoitov <ast@...nel.org>,
        alsa-devel@...a-project.org, Al Viro <viro@...iv.linux.org.uk>,
        Andrew Gabbasov <andrew_gabbasov@...tor.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Gross <agross@...nel.org>,
        Andy Lavr <andy.lavr@...il.com>,
        Arend van Spriel <aspriel@...il.com>,
        Baowen Zheng <baowen.zheng@...igine.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Bradley Grove <linuxdrivers@...otech.com>,
        brcm80211-dev-list.pdl@...adcom.com,
        Christian Brauner <brauner@...nel.org>,
        Christian Göttsche <cgzones@...glemail.com>,
        Christian Lamparter <chunkeey@...glemail.com>,
        Chris Zankel <chris@...kel.net>,
        Cong Wang <cong.wang@...edance.com>,
        David Gow <davidgow@...gle.com>,
        David Howells <dhowells@...hat.com>,
        "David S. Miller" <davem@...emloft.net>,
        Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>,
        devicetree@...r.kernel.org, Dexuan Cui <decui@...rosoft.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        Eli Cohen <elic@...dia.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Eric Paris <eparis@...isplace.org>,
        Eugeniu Rosca <erosca@...adit-jv.com>,
        Felipe Balbi <balbi@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Gregory Greenman <gregory.greenman@...el.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Hulk Robot <hulkci@...wei.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        James Morris <jmorris@...ei.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Jason Gunthorpe <jgg@...pe.ca>, Jens Axboe <axboe@...nel.dk>,
        Johan Hedberg <johan.hedberg@...il.com>,
        John Keeping <john@...anate.com>,
        Juergen Gross <jgross@...e.com>, Kalle Valo <kvalo@...nel.org>,
        keyrings@...r.kernel.org, kunit-dev@...glegroups.com,
        Kuniyuki Iwashima <kuniyu@...zon.co.jp>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Lee Jones <lee.jones@...aro.org>,
        Leon Romanovsky <leon@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        linux1394-devel@...ts.sourceforge.net,
        linux-afs@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, linux-bluetooth@...r.kernel.org,
        linux-hardening@...r.kernel.org, linux-hyperv@...r.kernel.org,
        linux-integrity@...r.kernel.org, linux-rdma@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-security-module@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-wireless@...r.kernel.org,
        linux-xtensa@...ux-xtensa.org, llvm@...ts.linux.dev,
        Loic Poulain <loic.poulain@...aro.org>,
        Louis Peens <louis.peens@...igine.com>,
        Luca Coelho <luciano.coelho@...el.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Marc Dionne <marc.dionne@...istor.com>,
        Marcel Holtmann <marcel@...tmann.org>,
        Mark Brown <broonie@...nel.org>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Max Filippov <jcmvbkbc@...il.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Muchun Song <songmuchun@...edance.com>,
        Nathan Chancellor <nathan@...nel.org>, netdev@...r.kernel.org,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nuno Sá <nuno.sa@...log.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Paul Moore <paul@...l-moore.com>,
        Rich Felker <dalias@...ifal.cx>,
        Rob Herring <robh+dt@...nel.org>,
        Russell King <linux@...linux.org.uk>, selinux@...r.kernel.org,
        "Serge E. Hallyn" <serge@...lyn.com>,
        SHA-cyfmac-dev-list@...ineon.com,
        Simon Horman <simon.horman@...igine.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Stefan Richter <stefanr@...6.in-berlin.de>,
        Steffen Klassert <steffen.klassert@...unet.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Takashi Iwai <tiwai@...e.com>, Tom Rix <trix@...hat.com>,
        Udipto Goswami <quic_ugoswami@...cinc.com>,
        wcn36xx@...ts.infradead.org, Wei Liu <wei.liu@...nel.org>,
        xen-devel@...ts.xenproject.org,
        Xiu Jianfeng <xiujianfeng@...wei.com>,
        Yang Yingliang <yangyingliang@...wei.com>
Subject: Re: [PATCH 02/32] Introduce flexible array struct memcpy() helpers

On Wed, May 04, 2022 at 09:25:56AM +0200, Johannes Berg wrote:
> On Tue, 2022-05-03 at 18:44 -0700, Kees Cook wrote:
> > 
> > For example, using the most complicated helper, mem_to_flex_dup():
> > 
> >     /* Flexible array struct with members identified. */
> >     struct something {
> >         int mode;
> >         DECLARE_FLEX_ARRAY_ELEMENTS_COUNT(int, how_many);
> >         unsigned long flags;
> >         DECLARE_FLEX_ARRAY_ELEMENTS(u32, value);
> 
> In many cases, the order of the elements doesn't really matter, so maybe
> it'd be nicer to be able to write it as something like
> 
> DECLARE_FLEX_STRUCT(something,
> 	int mode;
> 	unsigned long flags;
> 	,
> 	int, how_many,
> 	u32, value);
> 
> perhaps? OK, that doesn't seem so nice either.
> 
> Maybe
> 
> struct something {
> 	int mode;
> 	unsigned long flags;
> 	FLEX_ARRAY(
> 		int, how_many,
> 		u32, value
> 	);
> };

Yeah, I mention some of my exploration of this idea in the sibling reply:
https://lore.kernel.org/linux-hardening/202205040730.161645EC@keescook/#t

It seemed like requiring a structure be rearranged to take advantage of
the "automatic layout introspection" wasn't very friendly. On the other
hand, looking at the examples, most of them are already neighboring
members. Hmmm.

> or so? The long and duplicated DECLARE_FLEX_ARRAY_ELEMENTS_COUNT and
> DECLARE_FLEX_ARRAY_ELEMENTS seems a bit tedious to me, at least in cases
> where the struct layout is not the most important thing (or it's already
> at the end anyway).

The names aren't great, but I wanted to distinguish "elements" as the
array not the count. Yay naming.

However, perhaps the solution is to have _both_. i.e using
BOUNDED_FLEX_ARRAY(count_type, count_name, array_type, array_name) for
the "neighboring" case, and the DECLARE...{ELEMENTS,COUNT} for the
"split" case.

And DECLARE_FLEX_ARRAY_ELEMENTS could actually be expanded to include
the count_name too, so both methods could be "forward portable" to a
future where C grew the syntax for bounded flex arrays.

> 
> >     struct something *instance = NULL;
> >     int rc;
> > 
> >     rc = mem_to_flex_dup(&instance, byte_array, count, GFP_KERNEL);
> >     if (rc)
> >         return rc;
> 
> This seems rather awkward, having to set it to NULL, then checking rc
> (and possibly needing a separate variable for it), etc.

I think the errno return is completely required. I had an earlier version
of this that was much more like a drop-in replacement for memcpy that
would just truncate or panic, and when I had it all together, I could
just imagine hearing Linus telling me to start over because it was unsafe
(truncation may be just as bad as overflow) and disruptive ("never BUG"),
and that it should be recoverable. So, I rewrote it all to return a
__must_check errno.

Requiring instance to be NULL is debatable, but I feel pretty strongly
about it because it does handle a class of mistakes (resource leaks),
and it's not much of a burden to require a known-good starting state.

> But I can understand how you arrived at this:
>  - need to pass instance or &instance or such for typeof()
>    or offsetof() or such

Right.

>  - instance = mem_to_flex_dup(instance, ...)
>    looks too much like it would actually dup 'instance', rather than
>    'byte_array'

And I need an errno output to keep imaginary Linus happy. :)

>  - if you pass &instance anyway, checking for NULL is simple and adds a
>    bit of safety

Right.

> but still, honestly, I don't like it. As APIs go, it feels a bit
> cumbersome and awkward to use, and you really need everyone to use this,
> and not say "uh what, I'll memcpy() instead".

Sure, and I have tried to get it down as small as possible. The earlier
"just put all the member names in every call" version was horrid. :P I
realize it's more work to check errno, but the memcpy() API we've all
been trained to use is just plain dangerous. I don't think it's
unreasonable to ask people to retrain themselves to avoid it. All that
said, yes, I want it to be as friendly as possible.

> Maybe there should also be a realloc() version of it?

Sure! Seems reasonable. I'd like to see the code pattern for this
though. Do you have any examples? Most of what I'd been able to find for
the fragile memcpy() usage was just basic serialize/deserialize or
direct copying.

> > +/** __fas_bytes - Calculate potential size of flexible array structure
> 
> I think you forgot "\n *" in many cases here after "/**".

Oops! Yes, thank you. I'll fix these.

-Kees

-- 
Kees Cook

Powered by blists - more mailing lists