From: Kees Cook <keescook@chromium.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Jens Axboe <axboe@kernel.dk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Denis Efremov <efremov@linux.com>,
linux-block <linux-block@vger.kernel.org>,
linux-kernel-mentees@lists.linuxfoundation.org,
Peilin Ye <yepeilin.cs@gmail.com>,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Linux-kernel-mentees] [PATCH v2] block/floppy: Prevent kernel-infoleak in raw_cmd_copyout()
Date: Fri, 23 Jul 2021 15:22:12 -0700 [thread overview]
Message-ID: <202107231520.32B389411@keescook> (raw)
In-Reply-To: <CAK8P3a2oUgdaYicdHwWvCY-HqjrcBAEzYA5yc5Gw14RLLoLdug@mail.gmail.com>
On Thu, Jul 30, 2020 at 10:45:02PM +0200, Arnd Bergmann wrote:
> On Thu, Jul 30, 2020 at 8:10 PM Kees Cook <keescook@chromium.org> wrote:
> > On Thu, Jul 30, 2020 at 10:11:07AM +0200, Arnd Bergmann wrote:
> >
> > test_stackinit.c intended to use six cases (where "full" is in the sense
> > of "all members are named", this is intentionally testing the behavior
> > of padding hole initialization):
>
> Ok, so I read that correctly, thanks for confirming.
>
> > >
> > > struct test_big_hole var = *arg;
> >
> > So this one is a "whole structure copy" which I didn't have any tests
> > for, since I'd (perhaps inappropriately) assumed would be accomplished
> > with memcpy() internally, which means the incoming "*arg"'s padding holes
> > would be copied as-is. If the compiler is actually doing per-member copies
> > and leaving holes in "var" untouched, that's unexpected, so clearly that
> > needs to be added to test_stackinit.c! :)
>
> For some reason I remembered this not turning into a memcpy()
> somewhere, but I can't reproduce it in any of my recent attempts,
> just like what Denis found.
>
> > > or the a constructor like
> > >
> > > struct test_big_hole var;
> > > var = (struct test_big_hole){ .one = arg->one, .two=arg->two, .three
> > > = arg->three, .four = arg->four };
> > >
> > > Kees, do you know whether those two would behave differently?
> > > Would it make sense to also check for those, or am I perhaps
> > > misreading your code and it already gets checked?
> >
> > I *think* the above constructor would be covered under "full runtime
> > init", but it does also seem likely it would be handled similarly to
> > the "whole structure copy" in the previous example.
>
> I would assume that at least with C99 it is more like the
> "whole structure copy", based on the standard language of
>
> "The value of the compound literal is that of an unnamed
> object initialized by the initializer list. If the compound literal
> occurs outside the body of a function, the object has static
> storage duration; otherwise, it has automatic storage duration
> associated with the enclosing block."
>
> > I will go add more tests...
>
> Thanks!
Well, nearly exactly a year later, I've finally done this. :P
https://lore.kernel.org/lkml/20210723221933.3431999-1-keescook@chromium.org
--
Kees Cook
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
prev parent reply other threads:[~2021-07-23 22:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 14:19 [Linux-kernel-mentees] [PATCH] block/floppy: Prevent kernel-infoleak in raw_cmd_copyout() Peilin Ye
2020-07-29 9:07 ` Denis Efremov
2020-07-29 9:18 ` Denis Efremov
2020-07-29 9:46 ` Peilin Ye
2020-07-29 11:51 ` [Linux-kernel-mentees] [PATCH v2] " Peilin Ye
2020-07-29 12:58 ` Dan Carpenter
2020-07-29 13:22 ` Denis Efremov
2020-07-29 13:42 ` Dan Carpenter
2020-07-30 8:11 ` Arnd Bergmann
2020-07-30 18:10 ` Kees Cook
2020-07-30 20:45 ` Arnd Bergmann
2021-07-23 22:22 ` Kees Cook [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=202107231520.32B389411@keescook \
--to=keescook@chromium.org \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=dan.carpenter@oracle.com \
--cc=efremov@linux.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yepeilin.cs@gmail.com \
/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).