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]

Date:   Thu, 9 Apr 2020 21:04:42 +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 21:01, Theodore Y. Ts'o <tytso@....edu> wrote:
>
> On Thu, Apr 09, 2020 at 03:04:25PM +0200, Ard Biesheuvel wrote:
> > The following changes since commit 594e576d4b93b8cda3247542366b47e1b2ddc4dc:
> >
> >   efi/libstub/arm: Fix spurious message that an initrd was loaded (2020-03-29 12:08:18 +0200)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent
>
> Hi Ard,
>
> By any chance does this series fix a kexec failure which I bisected
> down to 0a67361dcdaa ("efi/x86: Remove runtime table address from
> kexec EFI setup data")?   Or if it doesn't, is this a known failure?
>

Hi Ted,

I wasn't aware of this issue, and this series will most likely not fix it.

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

Please involve me in the discussions on this issue.