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]

Message-ID: <CAHmME9pPTWB0so2-wXmmsMQn0WhqZWwVcbpMP15U=QCt57Q_cg@mail.gmail.com>
Date:   Sun, 10 Jul 2022 01:23:38 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     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

Hey Peter,

On 7/10/22, H. Peter Anvin <hpa@...or.com> wrote:
> 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>

Thanks for the ack. In case your ack here is meant to communicate
"good to go for random.git," I thought I should mention: while earlier
versions of this patch were against my random.git tree, this one (and
the previous) is against tip.git, because otherwise there'd be some
annoying conflicts when merging. So if it's not too much trouble, I
think it would make sense to apply this to tip.

Jason

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