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: Sun, 24 Mar 2024 19:43:24 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Clayton Craft <clayton@...ftyguy.net>, x86@...nel.org, linux-kernel@...r.kernel.org, 
	linux-efi@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, regressions@...ts.linux.dev
Subject: Re: x86_64 32-bit EFI mixed mode boot broken

On Sun, 24 Mar 2024 at 16:49, Hans de Goede <hdegoede@...hat.com> wrote:
>
> Hi,
>
> On 3/21/24 11:48 PM, Ard Biesheuvel wrote:
> > (cc Hans)
> >
> > On Thu, 21 Mar 2024 at 23:05, Clayton Craft <clayton@...ftyguy.net> wrote:
> >>
> >> I've been chasing a problem with 32-bit EFI mixed mode booting on two different
> >> (x86_64) Intel Bay Trail platforms, where the system reboots or hangs seemingly
> >> very early somewhere before or after loading the kernel. I've not been able to
> >> get any output from the kernel or stub over efifb when the issue happens[0], and
> >> do not have serial console access on these systems.
> >>
> >> v6.8 fails for me, and presumably so does everything back to v6.2. v6.1 is able
> >> to boot OK on these platforms with mixed mode, and it looks like there are a lot
> >> of changes from 6.1..6.2 for EFI/mixed mode booting.
> >
> > v6.1 just received some EFI related backports, so please check the
> > latest v6.1.y as well.
> >
> >> I did managed to bisect the
> >> issue to:
> >>
> >>         commit e2ab9eab324cdf240de89741e4a1aa79919f0196
> >>         Author: Ard Biesheuvel <ardb@...nel.org>
> >>         Date:   Tue Nov 22 17:10:02 2022 +0100
> >>
> >>             x86/boot/compressed: Move 32-bit entrypoint code into .text section
> >>
> >> However I'm not sure how to proceed from here, or if my bisect is all that
> >> useful since the commit seems to be in the middle of a bunch of changes I do not
> >> understand. I've been using systemd-boot to test this (both the full bootloader
> >> and UKI w/ the sd-boot stub). Is 32-bit mixed mode on x86_64 working for others?
> >>
> >
> > I usually test on 32-bit OVMF built with LOAD_X64_ON_IA32_ENABLE,
> > which allows the use of the compat entry point. This is different from
> > the EFI handover protocol, and I am not sure which one you are using.
> >
> > I have never had any reports, or noticed any issues myself. Last time
> > I tried (some weeks ago) it was working for me.
> > CC'ing Hans who may have more data points.
>
> I've been offline for most of the week and I see that in the mean time
> you seem to have found a fix, great.
>
> FWIW I have been booting everything up to 6.8.0 on my own mixed-mode
> Bay Trail tablets without issues, so the problem seems to be specific to
> certain BIOS-es.
>
> Please Cc me on the final fix, then I can test that early and double check
> that things don't regress on other mixed-mode Bay Trail devices.
>

Thanks.

I pushed another branch

https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=efi-clayton-3

which has a proper fix for the issue that you found.

As it turns out, the compat mixed mode (with handover protocol) was
broken from the beginning, and the change you identified just happened
to trigger it on your hardware.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ