From: Kees Cook <keescook@chromium.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Ard Biesheuvel <ardb@kernel.org>,
Alexander Potapenko <glider@google.com>,
Marco Elver <elver@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
kasan-dev@googlegroups.com, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] random: split initialization into early arch step and later non-arch step
Date: Mon, 26 Sep 2022 20:23:57 -0700 [thread overview]
Message-ID: <202209262017.D751DDC38F@keescook> (raw)
In-Reply-To: <CAHmME9pFDzyKJd5ixyB9E05jkZvHShFimbiQsGTcdQO1E5R0QQ@mail.gmail.com>
On Mon, Sep 26, 2022 at 08:52:39PM +0200, Jason A. Donenfeld wrote:
> On Mon, Sep 26, 2022 at 8:22 PM Kees Cook <keescook@chromium.org> wrote:
> > Can find a way to get efi_get_random_bytes() in here too? (As a separate
> > patch.) I don't see where that actually happens anywhere currently,
> > and we should have it available at this point in the boot, yes?
>
> No, absolutely not. That is not how EFI works. EFI gets its seed to
> random.c much earlier by way of add_bootloader_randomness().
Ah! Okay, so, yes, it _does_ get entropy in there, just via a path I
didn't see?
>
> > > - entropy[0] = random_get_entropy();
> > > - _mix_pool_bytes(entropy, sizeof(*entropy));
> > > arch_bits -= sizeof(*entropy) * 8;
> > > ++i;
> > > }
> > > - _mix_pool_bytes(&now, sizeof(now));
> > > - _mix_pool_bytes(utsname(), sizeof(*(utsname())));
> >
> > Hm, can't we keep utsname in the early half by using init_utsname() ?
>
> Yes, we could maybe *change* to using init_utsname if we wanted. That
> seems kind of different though. So I'd prefer that to be a different
> patch, which would require looking at the interaction with early
> hostname setting and such. If you want to do that work, I'd certainly
> welcome the patch.
Er, isn't that _WAY_ later? Like, hostname isn't set until sysctls up
and running, etc. I haven't actually verified 100% but it looks like
current->utsname is exactly init_utsname currently.
But if not, I guess it could just get added in both places. I'd be nice
to keep kernel version as part of the pre-time-keeping entropy stuffing.
> > Was there a reason kfence_init() was happening before time_init()?
>
> Historically there was, I think, because random_init() used to make
> weird allocations. But that's been gone for a while. At this point
> it's a mistake, and removing it allows me to do this:
>
> https://groups.google.com/g/kasan-dev/c/jhExcSv_Pj4
Cool. Is that true for all the -stable releases this is aimed at?
Anyway, just to repeat before: yay! I really like seeing this split up.
:)
--
Kees Cook
next prev parent reply other threads:[~2022-09-27 3:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-26 16:03 [PATCH] random: split initialization into early arch step and later non-arch step Jason A. Donenfeld
2022-09-26 16:22 ` Andrew Morton
2022-09-26 16:29 ` Jason A. Donenfeld
2022-09-26 18:22 ` Kees Cook
2022-09-26 18:52 ` Jason A. Donenfeld
2022-09-27 3:23 ` Kees Cook [this message]
2022-09-27 8:34 ` Jason A. Donenfeld
2022-09-27 9:30 ` Jason A. Donenfeld
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=202209262017.D751DDC38F@keescook \
--to=keescook@chromium.org \
--cc=Jason@zx2c4.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.