linux-kernel - Re: [PATCH v3] Support ESRT in Xen dom0

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:   Thu, 22 Sep 2022 08:12:14 +0200
From:   Jan Beulich <jbeulich@...e.com>
To:     Demi Marie Obenour <demi@...isiblethingslab.com>
Cc:     Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
        linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
        xen-devel@...ts.xenproject.org,
        Marek Marczykowski-Górecki 
        <marmarek@...isiblethingslab.com>, Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH v3] Support ESRT in Xen dom0

On 22.09.2022 03:09, Demi Marie Obenour wrote:
> On Wed, Sep 21, 2022 at 10:34:04PM +0200, Jan Beulich wrote:
>> On 20.09.2022 18:09, Ard Biesheuvel wrote:
>>> On Tue, 20 Sept 2022 at 17:54, Jan Beulich <jbeulich@...e.com> wrote:
>>>>
>>>> On 20.09.2022 17:36, Ard Biesheuvel wrote:
>>>>> On Mon, 19 Sept 2022 at 21:33, Demi Marie Obenour
>>>>> <demi@...isiblethingslab.com> wrote:
>>>>>>
>>>>>> fwupd requires access to the EFI System Resource Table (ESRT) to
>>>>>> discover which firmware can be updated by the OS.  Currently, Linux does
>>>>>> not expose the ESRT when running as a Xen dom0.  Therefore, it is not
>>>>>> possible to use fwupd in a Xen dom0, which is a serious problem for e.g.
>>>>>> Qubes OS.
>>>>>>
>>>>>> Before Xen 4.16, this was not fixable due to hypervisor limitations.
>>>>>> The UEFI specification requires the ESRT to be in EfiBootServicesData
>>>>>> memory, which Xen will use for whatever purposes it likes.  Therefore,
>>>>>> Linux cannot safely access the ESRT, as Xen may have overwritten it.
>>>>>>
>>>>>> Starting with Xen 4.17, Xen checks if the ESRT is in EfiBootServicesData
>>>>>> or EfiRuntimeServicesData memory.  If the ESRT is in EfiBootServicesData
>>>>>> memory, Xen allocates some memory of type EfiRuntimeServicesData, copies
>>>>>> the ESRT to it, and finally replaces the ESRT pointer with a pointer to
>>>>>> the copy.  Since Xen will not clobber EfiRuntimeServicesData memory,
>>>>>> this ensures that the ESRT can safely be accessed by the OS.  It is safe
>>>>>> to access the ESRT under Xen if, and only if, it is in memory of type
>>>>>> EfiRuntimeServicesData.
>>>>>>
>>>>>
>>>>> Thanks for the elaborate explanation. This is really helpful.
>>>>>
>>>>> So here, you are explaining that the only way for Xen to prevent
>>>>> itself from potentially clobbering the ESRT is by creating a
>>>>> completely new allocation?
>>>>
>>>> There are surely other ways, e.g. preserving BootServices* regions
>>>> alongside RuntimeServices* ones. But as the maintainer of the EFI
>>>> code in Xen I don't view this as a reasonable approach.
>>>
>>> Why not?
>>
>> Because it's against the intentions the EFI has (or at least had)
>> for this memory type. Much more than EfiAcpiReclaimMemory this
>> type is intended for use as ordinary RAM post-boot.
> 
> What about giving that memory to dom0?  dom0’s balloon driver will give
> anything dom0 doesn’t wind up using back to Xen.

While perhaps in principle possible, this would require special casing
in Xen. Except for the memory the initrd comes in, we don't directly
hand memory to Dom0. Instead everything goes through the page allocator
first. Plus if we really were convinced boot services memory needed
retaining, then it would also need retaining across kexec (and hence
shouldn't be left to Dom0 to decide what to do with it).

Jan