linux-kernel - Re: [PATCH] x86: temporarily remove all attempts to provide 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: <Y+PpRUYHDc1TH2zO@redhat.com>
Date:   Wed, 8 Feb 2023 18:26:13 +0000
From:   Daniel P. Berrangé <berrange@...hat.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     qemu-devel@...gnu.org, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Dov Murik <dovmurik@...ux.ibm.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Gerd Hoffmann <kraxel@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Richard Henderson <richard.henderson@...aro.org>,
        "H . Peter Anvin" <hpa@...or.com>,
        Philippe Mathieu-Daudé <philmd@...aro.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Eric Biggers <ebiggers@...nel.org>
Subject: Re: [PATCH] x86: temporarily remove all attempts to provide
 setup_data

On Wed, Feb 08, 2023 at 03:08:35PM -0300, Jason A. Donenfeld wrote:
> All attempts at providing setup_data have been made as an iteration on
> whatever was there before, stretching back to the original
> implementation used for DTBs that [mis]used the kernel image itself.
> We've now had a dozen rounds of bugs and hacks, and the result is
> turning into a pile of unmaintainable and increasingly brittle hacks.
> 
> Let's just rip out all the madness and start over. We can re-architect
> this based on having a separate standalone setup_data file, which is how
> it should have been done in the first place. This is a larger project
> with a few things to coordinate, but we can't really begin thinking
> about that while trying to play whack-a-mole with the current buggy
> implementation.
> 
> So this commit removes the setup_data setting from x86_load_linux(),
> while leaving intact the infrastructure we'll need in the future to try
> again.

Technically this changes the ABI of the 7.2.0 machine type version
which we would normally avoid.

In practice I think we can probably get away with doing it.

The number of released guest OS that consume the RNG seed is negligible
at this point in time. Any that do consume shouldn't mind much if it
just disappears on next boot, since it was always just an opt-in, and
the kernel will happily still boot without it.

So I'm fine if we just put a note in the commit message acknowledging
that this is an ABI incompatibility for the machine type, but explaining
why it is none the less OK todo in this exceptional circumstance.

> 
> Cc: Michael S. Tsirkin <mst@...hat.com>
> Cc: Dov Murik <dovmurik@...ux.ibm.com>
> Cc: Tom Lendacky <thomas.lendacky@....com>
> Cc: Gerd Hoffmann <kraxel@...hat.com>
> Cc: Daniel P. Berrangé <berrange@...hat.com>
> Cc: Paolo Bonzini <pbonzini@...hat.com>
> Cc: Richard Henderson <richard.henderson@...aro.org>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Philippe Mathieu-Daudé <philmd@...aro.org>
> Cc: Nathan Chancellor <nathan@...nel.org>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Eric Biggers <ebiggers@...nel.org>
> Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
> ---
>  hw/i386/microvm.c |  15 ++----
>  hw/i386/x86.c     | 120 +++++-----------------------------------------
>  2 files changed, 17 insertions(+), 118 deletions(-)

Presumably it should be purging all traces of the 'legacy_no_rng_seed'
at the same time, with the view that any future implementation would be
tied to only whatever machine type is current at the time it gets
merged (could be 8.0.0 or 8.1.0 machine type, depending on how quickly
the new design gets settled).

$ git grep legacy_no_rng_seed
hw/i386/pc.c:                   pcmc->pvh_enabled, pcmc->legacy_no_rng_seed);
hw/i386/pc.c:                       pcmc->pvh_enabled, pcmc->legacy_no_rng_seed);
hw/i386/pc_piix.c:    pcmc->legacy_no_rng_seed = true;
hw/i386/pc_q35.c:    pcmc->legacy_no_rng_seed = true;
hw/i386/x86.c:                    bool legacy_no_rng_seed)
hw/i386/x86.c:    if (!legacy_no_rng_seed) {
include/hw/i386/pc.h:    bool legacy_no_rng_seed;
include/hw/i386/x86.h:                    bool legacy_no_rng_seed);


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|