linux-hardening - Re: [PATCH] random: split initialization into early arch step and later non-arch step

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHmME9qTf+aDmBen2dFXPmbDGkn1E4=oXqqeBRiguLCo7K9EhQ@mail.gmail.com>
Date:   Tue, 27 Sep 2022 10:34:16 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Alexander Potapenko <glider@...gle.com>,
        Marco Elver <elver@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH] random: split initialization into early arch step and
 later non-arch step

On Tue, Sep 27, 2022 at 5:23 AM Kees Cook <keescook@...omium.org> wrote:
>
> 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@...omium.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?

Yes.

> > 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.

If init_utsname()==utsname() and all is fine, can you please send a
patch atop random.git adjusting that and explaining why? I would
happily take such a patch. If your suspicion is correct, it would make
a most welcome improvement.

> > > 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?

Yes.

Though I'll likely drop the stable@ tag for this, and instead visit
backporting it later in 6.1's cycle, or even after. There's no need to
rush it, and this is an area that has been historically temperamental.

Jason