[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] efi: discover ESRT table on Xen PV too




On 19.08.2020 10:19, Roger Pau Monné wrote:
On Tue, Aug 18, 2020 at 08:40:18PM +0200, Marek Marczykowski-Górecki wrote:
On Tue, Aug 18, 2020 at 07:21:14PM +0200, Roger Pau Monné wrote:
Let me draw the picture from the beginning.
Thanks, greatly appreciated.

EFI memory map contains various memory regions. Some of them are marked
as not needed after ExitBootServices() call (done in Xen before
launching dom0). This includes EFI_BOOT_SERVICES_DATA and
EFI_BOOT_SERVICES_CODE.

EFI SystemTable contains pointers to various ConfigurationTables -
physical addresses (at least in this case). Xen does interpret some of
them, but not ESRT. Xen pass the whole (address of) SystemTable to Linux
dom0 (at least in PV case). Xen doesn't do anything about tables it
doesn't understand.

Now, the code in Linux takes the (ESRT) table address early and checks
the memory map for it. We have 3 cases:
  - it points at area marked as neither EFI_*_SERVICES_DATA, nor with
    EFI_MEMORY_RUNTIME attribute -> Linux refuse to use it
  - it points to EFI_RUNTIME_SERVICES_DATA or with EFI_MEMORY_RUNTIME
    attribute - Linux uses the table; memory map already says the area
    belongs to EFI and the OS should not use it for something else
  - it points to EFI_BOOT_SERVICES_DATA - Linux mark the area as reserved
    to not release it after calling ExitBootServices()

The problematic is the third case - at the time when Linux dom0 is run,
ExitBootServices() was already called and EFI_BOOT_SERVICES_* memory was
already released. It could be already used for something else (for
example Xen could overwrite it while loading dom0).

Note the problematic case should be the most common - UEFI specification
says "The ESRT shall be stored in memory of type EfiBootServicesData"
(chapter 22.3 of UEFI Spec v2.6).

For this reason, to use ESRT in dom0, Xen should do something about it
before ExitBootServices() call. While analyzing all the EFI tables is
probably not a viable option, it can do some simple action:
  - retains all the EFI_BOOT_SERVICES_* areas - there is already code
    for that, controlled with /mapbs boot switch (to xen.efi, would need
    another option for multiboot2+efi)
  - have a list of tables to retain - since Xen already do analyze some
    of the ConfigurationTables, it can also have a list of those to
    preserve even if they live in EFI_BOOT_SERVICES_DATA. In this case,
    while Xen doesn't need to parse the whole table, it need to parse it's
    header to get the table size - to reserve that memory and not reuse
    it after ExitBootServices().
Xen seems to already contain skeleton
XEN_EFI_query_capsule_capabilities and XEN_EFI_update_capsule
hypercalls which is what should be used in order to perform the
updates?
I think those covers only runtime service calls similarly named. But you
need also ESRT table to collect info about devices that you can even
attempt to update.
Right, the ESRT must be available so that dom0 can discover the
resources.

TBH, I'm not sure if those runtime services are really needed. I think
Norbert succeeded UEFI update from within Xen PV dom0 with just access
to the ESRT table, but without those services.

Marek is right here. I was able to successfully update and downgrade
UFEI when the ESRT table was provided to the Xen PV dom0. I didn't
need any extra services to make the UEFI capsule update work.
OK, by reading the UEFI spec I assumed that you needed access to
QueryCapsuleCapabilities and UpdateCapsule in order to perform the
updates, and those should be proxied using hyopercalls. Maybe this is
not mandatory and there's a side-band mechanism of doing this?

I think we need more info here.

So yes, I agree Xen should make sure the region of the table is not
freed when exiting boot services, and that dom0 can access it. I
guess we should move the checks done by Linux to Xen, and then only
provide the ESRT table to dom0 if the checks (now done by Xen) pass.
Yes, something like this. But note currently in the (PV) dom0 case, Xen
provides dom0 with a pointer to the whole SystemTable, not individual
ConfigurationTables. Making it filter what dom0 gets would require Xen
to re-construct the whole thing with just those elements that are
desired. Not exactly sure if worth the effort given the privilege dom0
has.
We already do this for ACPI in PVH dom0, where Xen rebuilds the RSDT
in order to filter out tables that shouldn't be exposed to dom0. If
possible using something similar for UEFI would be my preference, but
I certainly haven't investigated at all whether this is feasible.

BTW How does it look in PVH dom0 case? Does it also get unmodified host
EFI SystemTable? In that case, it would be more tricky, because (IIUC)
physical addresses (like the one for ESRT table) are not meaningful to
PVH dom0.
For PVH dom0 we should make sure the ESRT is identity mapped into the
physmap, so that dom0 has access to it. PVH dom0 gets a physical
memory map that's basically the native one with the RAM regions
adjusted to match the assigned memory.

We already identity map a bunch of stuff there, so identity mapping
the ESRT would be likely fine.

It might be helpful to see the whole picture here with the hooks to
perform the updates also implemented, as those are missing in Xen (and
Linux?). That would give a clearer view of what you are trying to
achieve IMO.
Norbert, can you shed some light on this process?

While those two runtime services seems relevant, I see also an update
process involving simply dropping some file into ESP (/boot/efi). I'm
not sure if some runtime services were involved.
So then the update is done when rebooting? If we expose the ESRT we
should also make sure the run-time services related to it are
available.

Fwupd uses system firmware GUID to recognize its type. UEFI GUID is
provided in the ESRT. Then fwupd checks if the updates/downgrades are
available. In the next step the tool downloads and extracts cabinet
archives in the EFI capsule file format and the capsule updates firmware
after the OS reboot.

---
Best Regards,
Norbert Kamiński
Embedded Systems Engineer
GPG key ID: 9E9F90AFE10F466A
3mdeb.com




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.