linux-kernel - Re: [PATCH v4 1/2] Avoid using EFI tables Xen may have clobbered

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: <01d22092-8292-8ed7-ece7-9ca32d15bbce@suse.com>
Date:   Tue, 4 Oct 2022 10:22:13 +0200
From:   Jan Beulich <jbeulich@...e.com>
To:     Demi Marie Obenour <demi@...isiblethingslab.com>
Cc:     xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
        linux-efi@...r.kernel.org, Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
        Kees Cook <keescook@...omium.org>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>,
        Marek Marczykowski-Górecki 
        <marmarek@...isiblethingslab.com>, Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH v4 1/2] Avoid using EFI tables Xen may have clobbered

On 01.10.2022 02:30, Demi Marie Obenour wrote:
> On Fri, Sep 30, 2022 at 08:27:09PM +0200, Ard Biesheuvel wrote:
>> On Fri, 30 Sept 2022 at 19:12, Demi Marie Obenour wrote:
>>> On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheuvel wrote:
>>>> I know very little about Xen, but based on the context you provided in
>>>> this thread, I'd say that the best approach from the Xen side is to
>>>> convert all EfiBootServicesData regions that have configuration tables
>>>> pointing into them into EfiAcpiReclaimMemory.
>>>
>>> Should Xen convert the entire region, or should it try to reserve only
>>> the memory it needs?  The latter would require it to parse the
>>> configuration tables.  Is there a list of configuration tables that can
>>> legitimately be in EfiBootServicesData regions?
>>>
>>
>> Not really, no. So you would have to convert the entire region
>> /unless/ Xen knows the GUID, and therefore knows how to derive the
>> size of the table, allowing it to reserve memory more conservatively.
>> However, I doubt whether this is worth it: splitting entries implies
>> rewriting the memory map, which is a thing I'd rather avoid if I were
>> in your shoes.
> 
> I actually wonder if Xen needs to reserve *all* of EfiBootServicesData.
> The reason is that some (probably buggy) firmware may store ACPI tables
> there, and Xen does not have an ACPI implementation.

We already have the -mapbs option as a workaround in such situations.

>  From my
> perspective, a much safer approach would be to pass all of
> EfiBootServicesData memory directly to dom0, and have dom0 give Xen back
> what it doesn’t wind up using.  That allows dom0’s memory reservation
> code to work properly, which it currently does not.

As said already on a different thread: Giving memory to domains (incl
Dom0) isn't related to their original memory type (neither EFI's nor
E820's); the needed memory is taken from the general page allocator
(with one exception for initrd, to avoid unnecessary copying around of
data). Hence what you propose would end up as an (imo) awful hack in
Xen. I also don't see how this relates to "dom0’s memory reservation
code", but I'm sure you can clarify that for me.

Jan