linux-kernel - Re: [PATCH tip v9] x86/setup: Use rng seeds from setup

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sat, 9 Jul 2022 15:42:50 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH tip v9] x86/setup: Use rng seeds from setup_data

On 7/9/22 02:48, Jason A. Donenfeld wrote:
> Currently the only way x86 can get an early boot RNG seed is via EFI,
> which is generally always used now for physical machines, but is very
> rarely used in VMs, especially VMs that are optimized for starting
> "instantaneously", such as Firecracker's MicroVM. For tiny fast booting
> VMs, EFI is not something you generally need or want.
> 
> Rather, here we want the ability for the image loader or firmware to
> pass a single random seed, exactly as device tree platforms do with the
> "rng-seed" property. Additionally, this is something that bootloaders
> can append, with their own seed file management, which is something
> every other major OS ecosystem has that we do not (yet).
> 
> This patch adds SETUP_RNG_SEED, similar to the other seven setup_data
> entries that are parsed at boot. It also takes care to zero out the seed
> immediately after using, in order to retain forward secrecy. This all
> takes about 7 trivial lines of code.
> 
> Then, on kexec_file_load(), a new fresh seed is generated and passed to
> the next kernel, just as is done on device tree architectures when
> using kexec. And, importantly, I've tested that QEMU is able to properly
> pass SETUP_RNG_SEED as well, making this work for every step of the way.
> This code too is pretty straight forward.
> 
> Together these measures ensure that VMs and nested kexec()'d kernels
> always receive a proper boot time RNG seed at the earliest possible
> stage from their parents:
> 
>     - Host [already has strongly initialized RNG]
>       - QEMU [passes fresh seed in SETUP_RNG_SEED field]
>         - Linux [uses parent's seed and gathers entropy of its own]
>           - kexec [passes this in SETUP_RNG_SEED field]
>             - Linux [uses parent's seed and gathers entropy of its own]
>               - kexec [passes this in SETUP_RNG_SEED field]
>                 - Linux [uses parent's seed and gathers entropy of its own]
>                   - kexec [passes this in SETUP_RNG_SEED field]
> 		   - ...
> 
> I've verified in several scenarios that this works quite well from a
> host kernel to QEMU and down inwards, mixing and matching loaders, with
> every layer providing a seed to the next.
> 
> Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>

Acked-by: H. Peter Anvin (Intel) <hpa@...or.com>

> ---
> Changes v8->v9:
> - [hpa] Update SETUP_TYPE_MAX and add SETUP_ENUM_MAX.