linux-kernel - Re: [PATCH v7 2/9] x86/startup_64: Defer assignment of 5-level paging global variables

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: <20240303192654.GAZeTO_nxJ4bE2A2zD@fat_crate.local>
Date: Sun, 3 Mar 2024 20:26:54 +0100
From: Borislav Petkov <bp@...en8.de>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
	Kevin Loughlin <kevinloughlin@...gle.com>,
	Tom Lendacky <thomas.lendacky@....com>,
	Dionna Glaze <dionnaglaze@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Andy Lutomirski <luto@...nel.org>, Brian Gerst <brgerst@...il.com>
Subject: Re: [PATCH v7 2/9] x86/startup_64: Defer assignment of 5-level
 paging global variables

On Fri, Mar 01, 2024 at 06:33:23PM +0100, Borislav Petkov wrote:
> > I've built a debug OVMF image using the latest version of the series,
> > and put it at [0]
> > 
> > Run like this
> > 
> > qemu-system-x86_64 -M q35 \
> >   -cpu qemu64,+la57 -smp 4 \
> >   -bios OVMF-5level.fd \
> >   -kernel arch/x86/boot/bzImage \
> >   -append console=ttyS0\ earlyprintk=ttyS0 \
> >   -vga none -nographic -m 1g \
> >   -initrd <initrd.img>
> > 
> > and you will get loads of DEBUG output from the firmware first, and
> > then boot into Linux. (initrd can be omitted)
> > 
> > Right before entering, it will print
> > 
> > CpuDxe: 5-Level Paging = 1
> > 
> > which confirms that the firmware is running with 5 levels of paging.
> > 
> > I've confirmed that this boots happily with this series applied,
> > including when using 'no5lvl' on the command line, or when disabling
> > CONFIG_X86_5LEVEL [confirmed by inspecting
> > /sys/kernel/debug/page_tables/kernel].
> > 
> > 
> > [0] http://files.workofard.com/OVMF-5level.fd.gz
> 
> Nice, that might come in handy for other testing too.

Btw, on a semi-related note, do you have an idea whether a normal guest
kernel using OVMF istead of seabios would be even able to boot a kernel
supplied with -kernel like above but without an -initrd?

I have everything builtin and the same kernel boots fine in a guest with
a
[    0.000000] SMBIOS 3.0.0 present.
[    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014

but if I try to boot the respective guest installed with the OVMF BIOS
from the debian package:

[    0.000000] efi: EFI v2.7 by Debian distribution of EDK II
[    0.000000] efi: SMBIOS=0x7f788000 SMBIOS 3.0=0x7f786000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7ddfe018

it fails looking up the /dev/root device major/minor deep in the bowels
of the vfs:

[    2.565651] do_new_mount:
[    2.566380] vfs_get_tree: fc->root: 0000000000000000
[    2.567298] kern_path: filename: ffff88800d666000 of name: /dev/root
[    2.568418] kern_path: ret: 0
[    2.569009] lookup_bdev: kern_path(/dev/root, , path: ffff88800e537380), error: 0
[    2.571645] lookup_bdev: inode->i_rdev: 0x0
[    2.572417] get_tree_bdev: lookup_bdev(/dev/root, dev: 0x0), error: 0
						     ^^^^^^^^^

That dev_t should be 0x800002 - the major and minor of /dev/sda2 but it
looks like something else is missing in this case...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette