[v7,2/9] x86/startup_64: Defer assignment of 5-level paging global variables

  From: Ard Biesheuvel <ardb@kernel.org>

Assigning the 5-level paging related global variables from the earliest
C code using explicit references that use the 1:1 translation of memory
is unnecessary, as the startup code itself does not rely on them to
create the initial page tables, and this is all it should be doing. So
defer these assignments to the primary C entry code that executes via
the ordinary kernel virtual mapping.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/x86/include/asm/pgtable_64_types.h |  2 +-
 arch/x86/kernel/head64.c                | 44 +++++++-------------
 2 files changed, 15 insertions(+), 31 deletions(-)
  

On Tue, Feb 27, 2024 at 04:19:10PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> Assigning the 5-level paging related global variables from the earliest
> C code using explicit references that use the 1:1 translation of memory
> is unnecessary, as the startup code itself does not rely on them to
> create the initial page tables, and this is all it should be doing. So
> defer these assignments to the primary C entry code that executes via
> the ordinary kernel virtual mapping.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/x86/include/asm/pgtable_64_types.h |  2 +-
>  arch/x86/kernel/head64.c                | 44 +++++++-------------
>  2 files changed, 15 insertions(+), 31 deletions(-)

Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>

Those should probably be tested on a 5level machine, just in case.

Thx.
  

On Wed, 28 Feb 2024 at 21:56, Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Feb 27, 2024 at 04:19:10PM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > Assigning the 5-level paging related global variables from the earliest
> > C code using explicit references that use the 1:1 translation of memory
> > is unnecessary, as the startup code itself does not rely on them to
> > create the initial page tables, and this is all it should be doing. So
> > defer these assignments to the primary C entry code that executes via
> > the ordinary kernel virtual mapping.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  arch/x86/include/asm/pgtable_64_types.h |  2 +-
> >  arch/x86/kernel/head64.c                | 44 +++++++-------------
> >  2 files changed, 15 insertions(+), 31 deletions(-)
>
> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
>
> Those should probably be tested on a 5level machine, just in case.
>

I have tested this myself on QEMU with -cpu qemu64,+la57 and -cpu host+kvm using
- EFI boot (OVMF)
- legacy BIOS boot (SeaBIOS)
- with and without no5lvl on the command line
- with and without CONFIG_X86_5LEVEL

The scenario that I have not managed to test is entering from EFI with
5 levels of paging enabled, and switching back to 4 levels (which
should work regardless of CONFIG_X86_5LEVEL). However, no firmware in
existence actually supports that today, and I am pretty sure that this
code has never been tested under those conditions to begin with. (OVMF
patches are under review atm to allow 5-level paging to be enabled in
the firmware)

I currently don't have access to real hardware with LA57 support so
any additional coverage there is highly appreciated (same for the last
patch in this series)
  

On Fri, Mar 01, 2024 at 11:01:33AM +0100, Ard Biesheuvel wrote:
> The scenario that I have not managed to test is entering from EFI with
> 5 levels of paging enabled, and switching back to 4 levels (which
> should work regardless of CONFIG_X86_5LEVEL). However, no firmware in
> existence actually supports that today, and I am pretty sure that this
> code has never been tested under those conditions to begin with. (OVMF
> patches are under review atm to allow 5-level paging to be enabled in
> the firmware)

Aha.

> I currently don't have access to real hardware with LA57 support so
> any additional coverage there is highly appreciated (same for the last
> patch in this series)

Right, I'm sure dhansen could dig up such a machine. We'll ask him
nicely to test when the set is ready.

Thx.
  

On Fri, 1 Mar 2024 at 17:09, Borislav Petkov <bp@alien8.de> wrote:
>
> On Fri, Mar 01, 2024 at 11:01:33AM +0100, Ard Biesheuvel wrote:
> > The scenario that I have not managed to test is entering from EFI with
> > 5 levels of paging enabled, and switching back to 4 levels (which
> > should work regardless of CONFIG_X86_5LEVEL). However, no firmware in
> > existence actually supports that today, and I am pretty sure that this
> > code has never been tested under those conditions to begin with. (OVMF
> > patches are under review atm to allow 5-level paging to be enabled in
> > the firmware)
>
> Aha.
>

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
  

On Fri, Mar 01, 2024 at 06:09:53PM +0100, Ard Biesheuvel wrote:
> On Fri, 1 Mar 2024 at 17:09, Borislav Petkov <bp@alien8.de> wrote:
> >
> > On Fri, Mar 01, 2024 at 11:01:33AM +0100, Ard Biesheuvel wrote:
> > > The scenario that I have not managed to test is entering from EFI with
> > > 5 levels of paging enabled, and switching back to 4 levels (which
> > > should work regardless of CONFIG_X86_5LEVEL). However, no firmware in
> > > existence actually supports that today, and I am pretty sure that this
> > > code has never been tested under those conditions to begin with. (OVMF
> > > patches are under review atm to allow 5-level paging to be enabled in
> > > the firmware)
> >
> > Aha.
> >
> 
> 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.

Thx.
  

On 3/1/24 11:33, Borislav Petkov wrote:
> On Fri, Mar 01, 2024 at 06:09:53PM +0100, Ard Biesheuvel wrote:
>> On Fri, 1 Mar 2024 at 17:09, Borislav Petkov <bp@alien8.de> wrote:
>>>
>>> On Fri, Mar 01, 2024 at 11:01:33AM +0100, Ard Biesheuvel wrote:
>>>> The scenario that I have not managed to test is entering from EFI with
>>>> 5 levels of paging enabled, and switching back to 4 levels (which
>>>> should work regardless of CONFIG_X86_5LEVEL). However, no firmware in
>>>> existence actually supports that today, and I am pretty sure that this
>>>> code has never been tested under those conditions to begin with. (OVMF
>>>> patches are under review atm to allow 5-level paging to be enabled in
>>>> the firmware)
>>>
>>> Aha.
>>>
>>
>> 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.

Be aware that additional work will need to be done in OVMF to support 
5-level paging for SEV VMs.

Initial SEV implementation happened when there wasn't a page table library 
and so SEV support had to roll it's own page table modifications. A page 
table library has since been created and 5-level support was added, but 
the SEV code hasn't been converted over to use the new library, yet.

Thanks,
Tom

> 
> Thx.
>
  

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.
  

On Sun, 3 Mar 2024 at 20:27, Borislav Petkov <bp@alien8.de> wrote:
>
..
>
> 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?
>

How are you passing the root device to the kernel? Via root= on the
command line?

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

OK, so this is SeaBIOS

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

and this is OVMF.

I have tried both of these, with i440fx as well as q35, and they all
work happily with my Debian guest image passed via -hda to QEMU, and
with root=/dev/sda2 on the kernel command line.


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

How did you get this output? Are these debug printk()s you added yourself?
  

On Sun, Mar 03, 2024 at 10:56:49PM +0100, Ard Biesheuvel wrote:
> How are you passing the root device to the kernel? Via root= on the
> command line?

Yeah:

qemu
..
-kernel arch/x86/boot/bzImage
-append "root=/dev/sda2 resume=/dev/sda3 ...

> and this is OVMF.

Yap.

> I have tried both of these, with i440fx as well as q35, and they all
> work happily with my Debian guest image passed via -hda to QEMU, and
> with root=/dev/sda2 on the kernel command line.

Interesting. I'm not passing any machine type. Maybe I should even
thought I've never done it before.

/me goes and tries machine type.

Well, I'll be damned!

-machine type=pc-i440fx-2.8 - no workie BUT

-machine type=pc-q35-2.8

booted.

Now on to figure out what's different with q35 and why it is magical and
it finds the root device just fine:

[    2.732908] mount_root_generic: i: 2, fs_name: ext4
[    2.734275] do_mount_root: name: /dev/root
[    2.735093] kern_path: filename: ffff88800d4de000 of name: /root
[    2.736954] kern_path: ret: 0
[    2.737727] init_mount: kern_path(/root), ret: 0
[    2.738964] path_mount: will do_new_mount
[    2.739784] do_new_mount: 1, fc source: (null)
[    2.740961] do_new_mount: 2, err: 0
[    2.741722] do_new_mount: 3, err: 0
[    2.742448] do_new_mount: 4, err: 0
[    2.743164] vfs_get_tree: fc->root: 0000000000000000
[    2.744095] kern_path: filename: ffff88800d4de000 of name: /dev/root
[    2.745352] kern_path: ret: 0
[    2.745994] lookup_bdev: kern_path(/dev/root, , path: ffff88800cf163c0), error: 0
[    2.747288] lookup_bdev: inode->i_rdev: 0x800002
[    2.748163] get_tree_bdev: lookup_bdev(/dev/root, dev: 0x800002), error: 0
							  ^^^^^^^^^

> How did you get this output? Are these debug printk()s you added yourself?

Yeah, the good old "sprinkle printks" debugging method. Figured I should
look at the VFS code out of interest. :-)

Thanks a lot for the suggestions, especially about q35!