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:   Wed, 21 Sep 2022 21:53:47 -0400
From:   Demi Marie Obenour <demi@...isiblethingslab.com>
To:     Ard Biesheuvel <ardb@...nel.org>, Jan Beulich <jbeulich@...e.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
Subject: Re: [PATCH v3] Support ESRT in Xen dom0

On Tue, Sep 20, 2022 at 06:09:49PM +0200, 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.
> > >>
> > > TBH I still don't think this is a scalable approach. There are other
> > > configuration tables that may be passed in EFI boot services memory,
> > > and MS especially were pushing back in the UEFI forum on adding table
> > > types that were passed in anything other the EfiBootServicesData.
> >
> > Within Xen we might abstract the approach currently implemented in
> > case more such pieces of data appear.
> >
> > While I can easily believe MS might be advocating for this model,
> > I view it as problematic not only for Xen. How would you pass on
> > this information across kexec, for example, without introducing
> > further producer-consumer dependencies requiring separate protocols
> > to be followed?
> >
> 
> In this case, I don't think this is unreasonable for configuration
> tables, which only have a GUID and a base address. If the OS knows the
> GUID, and knows how to interpret the contents, it can decide for
> itself whether or not to preserve it. If it doesn't know the GUID, the
> memory is just treated as available memory [after EBS()]

Should an OS uninstall any configuration tables that it does not
preserve if it ever plans to kexec()?  Does Linux do this?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)