lkml.org 
[lkml]   [2023]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI
> > I still don't understand why we need to support every imaginable
> > combination of firmware, bootloader and OS. Unaccepted memory only
> > exists on a special kind of virtual machine, which provides very
> > little added value unless you opt into the security and attestation
> > features, which are all heavily based on firmware protocols. So why
> > should care about a EFI-aware bootloader calling ExitBootServices()
> > and subsequently doing a legacy boot of Linux on such systems?
>
> Why break what works? Some users want it.
>

The users that want legacy boot features will not be broken, they'll
only get a safe view of the memory map. I don't think it's right to
choose unsafe behavior for a legacy setup.

> This patch adds complexity, breaks what works and the only upside will
> turn into a dead weight soon.
>
> There's alternative to add option to instruct firmware to accept all
> memory from VMM side. It will serve legacy OS that doesn't know about
> unaccepted memory and it is also can be use by latency-sensitive users
> later on (analog of qemu -mem-prealloc).
>

This means that users of a distro that has not enabled unaccepted
memory support cannot simply start a VM with the usual command, but
instead have to know a baroque extra flag to get access to all the
memory that they configured the machine (and for a CSP customer, paid
for). That's not a good experience.

With GCE at least, you can't (shouldn't) associate the boot feature
flag with a disk image because disks are mutable. If a customer
upgrades their kernel after initially starting their VM, they can't
remove the flag due to the way image annotations work.

All of this headache goes away by adopting a small patch to the kernel
that calls a 0-ary protocol interface and keeping safe acceptance
behavior in the firmware. I think Gerd is right here that we should
treat it as a transition feature that we can remove later.

> --
> Kiryl Shutsemau / Kirill A. Shutemov



--
-Dionna Glaze, PhD (she/her)

\
 
 \ /
  Last update: 2023-03-26 23:43    [W:0.073 / U:1.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site