Re: [PATCH] docs: UEFI Secure Boot security policy

[Ross Lagerwall <ross.lagerwall@xxxxxxxxx>]

On Thu, Jun 12, 2025 at 1:21 PM Teddy Astie <teddy.astie@xxxxxxxxxx> wrote:
>
> Le 12/06/2025 à 12:08, Jan Beulich a écrit :
> > On 12.06.2025 01:58, Andrew Cooper wrote:
> >> +
> >> +Lockdown Mode
> >> +^^^^^^^^^^^^^
> >> +
> >> +A mode which causes the enforcement of the properties necessary to 
> >> conform to
> >> +the Secure Boot specification.  Lockdown Mode is forced active when Secure
> >> +Boot is active in the platform, but may be activated independently too for
> >> +development purposes with the ``lockdown`` command line option.
> >> +
> >> +TODO
> >> +^^^^
> >> +
> >> + * Command Line
> >> + * Livepatching
> >> + * Kexec
> >> + * Userspace hypercalls
> >
> > What about Dom0 being able to access almost(?) all memory, including all 
> > MMIO?
> > In this context, isn't iommu=dom0-strict a requirement for SB (while that's
> > still not the default mode of operation for PV Dom0, despite me keeping to
> > suggest that we ought to change that default)?
> >
>
> Unless I missed something, the kernel is not a part of the TCB in this
> Secure Boot model. But at some point, we definitely want to reduce the
> TCB to just Xen, and put a more limited trust on the control domains.
>
> Yet, the current plan of hardening the privcmd device is going to be
> very hard for sure.
>
> dom0-iommu=strict is a good mitigations in case untrusted parties of the
> dom0 get direct access to a devices. However, as it is now, it implies a
> IOTLB flush for each grant mapping done, which severely impede PV
> performance (PV-IOMMU patches can help solving this performance problem
> though).
>

The dom0 kernel is part of the TCB since it controls the hardware (along
with Xen). This is covered by the paragrah starting "Privileged code
shall include Xen and the kernel(s) of the control and hardware
domain...".

Dom0 being able to access all memory including MMIO is fine as long as
it does not get exposed to userspace. In general, the existing Linux
kernel lockdown mode would cover this by blocking /dev/mem, access to
resources in sysfs, etc.

Ross