linux-kernel - Re: [GIT PULL 0/9] EFI fixes for v5.7-rc

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: <CAMj1kXFqKGSqm_y+ht4mmmu10TrhSyiTG8V3PxRYGodpZ=xNFQ@mail.gmail.com>
Date:   Thu, 9 Apr 2020 23:29:06 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     linux-efi <linux-efi@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Borislav Petkov <bp@...e.de>,
        Colin Ian King <colin.king@...onical.com>,
        Gary Lin <glin@...e.com>, Jiri Slaby <jslaby@...e.cz>,
        Sergey Shatunov <me@...k.pw>, Takashi Iwai <tiwai@...e.de>
Subject: Re: [GIT PULL 0/9] EFI fixes for v5.7-rc

On Thu, 9 Apr 2020 at 22:16, Theodore Y. Ts'o <tytso@....edu> wrote:
>
> On Thu, Apr 09, 2020 at 09:04:42PM +0200, Ard Biesheuvel wrote:
> >
> > > I'm currently building Linus's latest branch to see if it's been fixed
> > > since v5.6-11114-g9c94b39560c3 (which is where I first noticed it) and
> > > while I was waiting for v5.6-12349-g87ebc45d2d32 to finish building so
> > > I could test it, I noticed these patches, and so I figured I'd fire
> > > off this quick question.
> > >
> >
> > I think we might be able to downright revert that patch if the
> > underlying assumption on my part is inaccurate, which was that the
> > fact that the boot code no longer uses the runtime table address
> > implies that there is no longer a reason to pass it.
>
> Unfortunately, it doesn't cleanly revert, which is why I started
> checking to see if it might be fixed already before trying to figure
> out how to do a manual revert.  I just tested and the tip of Linus's
> tree still has the failure.
>
> The short description of the failure: I'm using Debian Stable (Buster)
> with a 4.19 distro kernel and kexec-tools 2.0.18 to kexec into the
> kernel under test.  I'm using a Google Compute Engine VM, and the
> actual kexec command is here:
>
> https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/files/usr/local/lib/gce-kexec#L146
>
> What happens is that the kexec'ed kernel immediately crashes, at which
> point we drop back into the BIOS, and then it boots the Debain 4.19.0
> distro kernel instead of the kernel to be tested boot.  Since we lose
> the boot command line that was used from the kexec, the gce-xfstests
> image retries the kexec, which fails, and the failing kexec repeats
> until I manually kill the VM.
>
> The bisect fingred v5.6-rc1-59-g0a67361dcdaa ("efi/x86: Remove runtime
> table address from kexec EFI setup data") as the first failing commit.
> Its immediate parent commit, v5.6-rc1-58-g06c0bd93434c works just
> fine.
>
> Is there any further debugging information that would be useful?
>

Does this help at all?

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 781170d36f50..52f8138243df 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -180,6 +180,7 @@ extern void __init
efi_uv1_memmap_phys_epilog(pgd_t *save_pgd);

 struct efi_setup_data {
        u64 fw_vendor;
+       u64 __unused;
        u64 tables;
        u64 smbios;
        u64 reserved[8];