Re: SecureBoot requirements regarding Dom0

["Roger Pau Monné" <roger.pau@citrix.com>]

On Mon, Feb 23, 2026 at 01:42:39PM +0000, Teddy Astie wrote:
> I have some questions regarding SecureBoot and Xen.
> The only document that appears to define some sort of policy between Xen 
> and SecureBoot is this one 
> https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html.
> That is also similar to discussions made in SecureBoot-related talks.
> 
>  > Within the Xen architecture, Xen, the control domain and hardware 
> domain share responsibility for running and administering the platform. 
> This makes their kernels privileged as far as Secure Boot is concerned.
> 
> Why does SecureBoot needs to expand to Dom0 kernel ? If you e.g restrict 
> DMA through IOMMU and restrict some key hypercalls like kexec (among 
> some others), Dom0 shouldn't be able to compromise Xen (in principle); 
> hence can't escape SecureBoot boundaries.
> 
> SecureBoot doesn't appears to require preventing device access from 
> "unprivileged code" otherwise VFIO wouldn't be allowed under SecureBoot. 
> But such device access still needs to be contained (e.g through IOMMU 
> enforcement), that's something Xen already supports (e.g 
> dom0-iommu=strict / PVH Dom0).

What about the platform operations that deal with runtime services?
Those could mess up with the firmware, and are available to dom0.  Not
allowing dom0 to use those might result in a crippled dom0, for
example not being able to change the boot entries.

dom0 also gets access to (almost) all the IO ports and IO mem space,
plus also unmediated access to almost all the PCI config space, which
includes access to the root complex registers.

Or another example, the low 1M is accessible by a PV dom0 as IO memory
IIRC.  That's also where Xen places the AP startup trampoline.  Dom0
could modify that region and thus inject malicious code directly into
the AP startup path.  Then doing CPU unplug and hotplug would execute
that injected code.  We should probably adjust that in
dom0_setup_permissions() so dom0 cannot map the trampilone page, but
this is just an example of possibly many places dom0 has traditionally
been considered trusted, and that would likely be against a sane
Secure Boot policy.

> In that case, devices are only allowed to access Dom0, but can't access 
> outside of it.
> 
>  From a technical standpoint, PVH Dom0 setups (and also PV Dom0 
> depending on configuration) acts very similarly to a SecureBoot-able 
> Linux kernel which runs a KVM virtual machine with all host devices 
> passed-through it (using vfio-pci).

As said above - there's a bit more to it.

I'm not saying it can be done, but we are certainly not there yet.
And we don't even know exactly what would need limiting, due to the
assumption always been made about dom0 being trusted.

Regards, Roger.