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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.06.2025 01:58, Andrew Cooper wrote:
> Obviously RFC at this point.  It's worth saying that XenServer is intending to
> use Shim and get a signature from Microsoft, retaining all exiting features
> such as Livepatching and Kexec crash reporting.
> 
> This trails off into more TODOs towards the end.  Individual tasks should
> expand on the start made and resulting conversation from this thread.  As a
> reminder, the target audience for this doc is an administrator running a Xen
> deployment, but who is not necesserily a developer.
> 
> Several things are hard to express and want further discussion.  Suggestions
> welcome:
> 
> 1) Content of CONFIG_CMDLINE and the various CONFIG_*_DEFAULT options.  Xen is
> not going to be issuing XSAs for "downstream chose an unsafe configuration,
> then signed and deployed the result", yet Xen probably should be on the hook
> for bad "default ..." settings in Kconfig.

Imo it simply needs stating largely like this. As indicated by Marek, some
annotations are going to be needed to help people realize what is or is not
safe to use. If we wrongly marked a command line option (or Kconfig setting,
if applicable there) as safe to use, I think we'd be on the hook to issue an
XSN or XSA.

> 2) Pre-boot DMA Protection.  Microsoft consider this a platform feature
> requiring OEM enablement, and do not consider its absence to be a Secure Boot
> vulnerability.  But, it is less clear what the policy ought to be for Xen
> booting on a capable system and failing to do a correct live-handover of the
> IOMMU across ExitBootServices().

Shouldn't this be another TODO item at the bottom? We don't support yet taking
over when the IOMMUs are already enabled, do we?

> 3) The AMD microcode signature vulnerability.  While it's not Xen's bug per
> say, it's clearly a Secure Boot bypass because we do offer microcode loading
> capabilties to userspace, and malicious userspace can load an unauthorised
> microcode which allows them to read/write physical memory and bypass further
> signature checks.

While in general I continue to think that people ought to be paying attention
to advisories from HW vendors, we can certainly continue to issue at least
XSNs in such events.

> 4) Userspace Hypercalls.  To anyone who isn't already aware, /dev/xen/privcmd
> in the various Unicies is a giant priv-esc hole, as root userspace can
> e.g. issue direct memory hypercalls behind the back of an (intentionally)
> oblivious kernel, and cannot be handwaved away as "it's fine because it's
> root" under Secure Boot.  It's not a Xen vuln (Xen *does* audit pointers in
> guest hypercalls), but it is a guest kernel vuln because of failing to
> correctly audit hypercall parameters.  However, it does require substantial
> changes in Xen in order to allow guest kernels to do something half-way safe.

I'm having trouble seeing what's "hard to express" here. Auditing needs to be
added in kernels wanting to act as hwdom or ctldom. Flaws there would
require advisories (and revocation) by respective parties; for Linux that
would still be the Xen Security Team.

IOW imo this wording could just move down to the respective sub-item of the
TODO section.

> +Principles
> +^^^^^^^^^^
> +
> + * Privileged code shall include Xen and the kernel(s) of the control and
> +   hardware domain (both, if they're split).  While there is a privilege 
> split
> +   here in Xen's regular security model, they are equal from Secure Boot's
> +   point of view.

In this context, may I direct your attention to Jason's plans for Xenstore
domain? It, in the SILO model, being permitted interaction with the other
two special types might end up being a problem here.

See https://lists.xen.org/archives/html/xen-devel/2025-06/msg00703.html.

> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.

Isn't this an overstatement? None of the below had even parts thereof go
in so far.

> +Secure Boot Advanced Targeting
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +SBAT is a recovation scheme for Secure Boot enabled components, using a
> +generation based scheme.  See `Shim SBAT.md
> +<https://github.com/rhboot/shim/blob/main/SBAT.md>`_ for full details.
> +
> +Upstream Xen provides the infrastructure to embed SBAT metadata in
> +``xen.efi``, but does not maintain a generation number itself.  Downstreams
> +are expected to maintain their own generation numbers.
> +
> +
> +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)?

As a general remark (no good place to put it): In the eventual final patch I
expect a reference to this new doc is going to be inserted in the respective
section in SUPPORT.md.

Jan