Written to be solution and deployment neutral in order to focus on the
technology itself.  This policy is intended to work as well for UKI as for the
"classic server setup" approach.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: security@xen.org
CC: Juergen Gross <jgross@suse.com>
CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
CC: Trammell Hudson <hudson@trmm.net>
CC: Ross Lagerwall <ross.lagerwall@cloud.com>
CC: Frediano Ziglio <frediano.ziglio@cloud.com>
CC: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
CC: Kevin Lampis <kevin.lampis@cloud.com>

A rendered version is available at:
  https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html

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.

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().

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.

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.
---
 docs/admin-guide/index.rst            |   1 +
 docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++
 2 files changed, 135 insertions(+)
 create mode 100644 docs/admin-guide/uefi-secure-boot.rst

diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
index 54e6f65de347..e7895ee95001 100644
--- a/docs/admin-guide/index.rst
+++ b/docs/admin-guide/index.rst
@@ -5,4 +5,5 @@ Admin Guide
 
 .. toctree::
    introduction
+   uefi-secure-boot
    microcode-loading
diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/uefi-secure-boot.rst
new file mode 100644
index 000000000000..0e0f50143892
--- /dev/null
+++ b/docs/admin-guide/uefi-secure-boot.rst
@@ -0,0 +1,134 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+UEFI Secure Boot
+================
+
+UEFI Secure Boot is a verification mechanism, intended to ensure that only
+code trusted by the platform can run.  This is to prevent malicious code from
+hijacking the system.  Secure Boot requires that all privileged code be
+signed, and that there is a trust relationship with the platform; i.e. code
+which is not signed by a key enrolled in platform must not run privileged.
+
+Within the Xen architecture, Xen, the :term:`control domain` and
+:term:`hardware domain` share responsibility for running and administering the
+platform.  This makes their kernels privileged as far as Secure Boot is
+concerned.
+
+When Secure Boot is active in the platform, privileged code is required to not
+run any untrusted code (i.e. not run any code for which there is not a good
+signature), and is required not to allow this restriction to be bypassed
+(e.g. by command line request).
+
+
+Support in Xen
+--------------
+
+There are multiple ways to achieve this security goal, with differing
+tradeoffs for the eventual system.
+
+On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
+with the dom0 kernel and init-ramdisk, with an embedded command line, and with
+livepatching and kexec compiled out, and suitably signed.  The signature is
+checked by the bootloader and, as this covers all the privileged code, Xen
+doesn't need to perform further checks itself.
+
+On the other end of the spectrum is maintaining the features of existing
+deployments.  e.g. Xen needs signature checking capabilities for the dom0
+kernel, livepatches and kexec kernels, and needs to allow the use of safe
+command line options while disallowing unsafe ones.
+
+It is important to remember that Xen is one piece of the larger platform,
+where every piece depends on the correct functioning of all earlier pieces.  A
+product supporting Secure Boot requires a holistic approach involving all
+components in the system.  It is not sufficient to consider Xen in isolation.
+
+.. TODO: Move "In Progress" tasks here as they become ready
+
+Security Scope
+--------------
+
+Vulnerabilities impacting Secure Boot require a fixed component to be produced
+and distributed, the vulnerable component to be revoked, and the revocation
+distributed to platforms.
+
+The following principles and guidelines indicate where Secure Boot differs
+from more traditional security models, and the situations in which extra
+remediation may be necessary.
+
+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.
+
+ * Root or ADMIN in userspace is unprivileged from Secure Boot's point of
+   view, and must not be able to alter the enforcement policy or load unsigned
+   code even by e.g. editing a configuration file and rebooting.
+
+Within Scope
+^^^^^^^^^^^^
+
+The following types of issue require remediation and revocation of vulnerable
+binaries.
+
+ * Any failure to apply enforcements even against traditionally-privileged
+   userspace, including failure to authenticate new code to run and failure to
+   handle revocations properly.
+
+ * Any Out-of-Bounds write capable of altering the enforcement policy, or
+   capable of bypassing enforcement, e.g. by corrupting the running code.
+
+Out of Scope
+^^^^^^^^^^^^
+
+While typically a security issue in their own rights, these issues do not
+constitute a Secure Boot vulnerability, and do not require special
+remediation.
+
+ * Denial of Service vulnerabilities.
+
+ * Out-of-Bounds reads.
+
+The Xen Security Team will endeavour to produce XSAs for all violations of
+this security policy, including identifying them specifically as requiring
+further remediation by downstreams.
+
+
+In Progress
+-----------
+
+.. warning::
+
+   The following work is still in progress.  It is provisional, and not
+   security supported yet.
+
+
+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
-- 
2.39.5

On Thu, Jun 12, 2025 at 12:58 AM Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
...
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.
> +
> +
> +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

These two are also in progress since they have had patch series posted:

> + * Livepatching
> + * Kexec

I think a section on PCI passthrough is also warranted. i.e. preventing misuse
of a device to exploit Secure Boot.

Ross

On Thu, Jun 19, 2025 at 03:16:51PM +0100, Ross Lagerwall wrote:
> I think a section on PCI passthrough is also warranted. i.e. preventing misuse
> of a device to exploit Secure Boot.

While I agree it makes sense, I wonder if it's in scope for UEFI
Secure Boot as defined by Microsoft? It may have implication for example
on PCI passthrough to a PV domains.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

On Thu, 19 Jun 2025, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 19, 2025 at 03:16:51PM +0100, Ross Lagerwall wrote:
> > I think a section on PCI passthrough is also warranted. i.e. preventing misuse
> > of a device to exploit Secure Boot.
> 
> While I agree it makes sense, I wonder if it's in scope for UEFI
> Secure Boot as defined by Microsoft? It may have implication for example
> on PCI passthrough to a PV domains.

If we bring DomUs into the discussion, then I think we need to make a
distinction between predefined DomUs, which could have signatures
verified by Secure Boot (such as Dom0 and hyperlaunch/dom0less guests),
and other dynamically created DomUs which could be fetched from the
network and potentially started without signature verification or prior
knowledge.

On Thu, Jun 19, 2025 at 12:56:12PM -0700, Stefano Stabellini wrote:
> On Thu, 19 Jun 2025, Marek Marczykowski-Górecki wrote:
> > On Thu, Jun 19, 2025 at 03:16:51PM +0100, Ross Lagerwall wrote:
> > > I think a section on PCI passthrough is also warranted. i.e. preventing misuse
> > > of a device to exploit Secure Boot.
> > 
> > While I agree it makes sense, I wonder if it's in scope for UEFI
> > Secure Boot as defined by Microsoft? It may have implication for example
> > on PCI passthrough to a PV domains.
> 
> If we bring DomUs into the discussion, then I think we need to make a
> distinction between predefined DomUs, which could have signatures
> verified by Secure Boot (such as Dom0 and hyperlaunch/dom0less guests),
> and other dynamically created DomUs which could be fetched from the
> network and potentially started without signature verification or prior
> knowledge.

I think it's mostly not about what's running inside domU, but what such
domU has access to. The obvious part is enforcing IOMMU configuration so
that domU cannot use a PCI device as a proxy to modify hypervisor (or
dom0) code. But there may be more subtleties like access to specific
devices (HECI? SPI?).
Anyway, lets figure out first _if_ we need to do something about this
topic, and only then worry how.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

On Thu, Jun 19, 2025 at 11:06 PM Marek Marczykowski-Górecki
<marmarek@invisiblethingslab.com> wrote:
>
> On Thu, Jun 19, 2025 at 12:56:12PM -0700, Stefano Stabellini wrote:
> > On Thu, 19 Jun 2025, Marek Marczykowski-Górecki wrote:
> > > On Thu, Jun 19, 2025 at 03:16:51PM +0100, Ross Lagerwall wrote:
> > > > I think a section on PCI passthrough is also warranted. i.e. preventing misuse
> > > > of a device to exploit Secure Boot.
> > >
> > > While I agree it makes sense, I wonder if it's in scope for UEFI
> > > Secure Boot as defined by Microsoft? It may have implication for example
> > > on PCI passthrough to a PV domains.
> >
> > If we bring DomUs into the discussion, then I think we need to make a
> > distinction between predefined DomUs, which could have signatures
> > verified by Secure Boot (such as Dom0 and hyperlaunch/dom0less guests),
> > and other dynamically created DomUs which could be fetched from the
> > network and potentially started without signature verification or prior
> > knowledge.
>
> I think it's mostly not about what's running inside domU, but what such
> domU has access to. The obvious part is enforcing IOMMU configuration so
> that domU cannot use a PCI device as a proxy to modify hypervisor (or
> dom0) code. But there may be more subtleties like access to specific
> devices (HECI? SPI?).
> Anyway, lets figure out first _if_ we need to do something about this
> topic, and only then worry how.
>

As far as I know, Microsoft haven't specified requirements to this level
of detail. However, if userspace can break the Secure Boot principles
laid out above using a (spec compliant) PCI device to write memory, then
I don't see why it would be any different to a Secure Boot compromise
using the CPU to write memory. Linux prevents direct access to PCI
devices when lockdown mode is enabled, presumably to prevent these kinds
of attacks.

Ross

On Thu, 12 Jun 2025, Andrew Cooper wrote:
> Written to be solution and deployment neutral in order to focus on the
> technology itself.  This policy is intended to work as well for UKI as for the
> "classic server setup" approach.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: security@xen.org
> CC: Juergen Gross <jgross@suse.com>
> CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> CC: Trammell Hudson <hudson@trmm.net>
> CC: Ross Lagerwall <ross.lagerwall@cloud.com>
> CC: Frediano Ziglio <frediano.ziglio@cloud.com>
> CC: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
> CC: Kevin Lampis <kevin.lampis@cloud.com>
> 
> A rendered version is available at:
>   https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html
> 
> 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.
> 
> 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().
> 
> 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.
> 
> 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.

One small suggestion for improvement is that Secure Boot is not an
x86-specific specification so we should keep the document arch-neutral.


> ---
>  docs/admin-guide/index.rst            |   1 +
>  docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++
>  2 files changed, 135 insertions(+)
>  create mode 100644 docs/admin-guide/uefi-secure-boot.rst
> 
> diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
> index 54e6f65de347..e7895ee95001 100644
> --- a/docs/admin-guide/index.rst
> +++ b/docs/admin-guide/index.rst
> @@ -5,4 +5,5 @@ Admin Guide
>  
>  .. toctree::
>     introduction
> +   uefi-secure-boot
>     microcode-loading
> diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/uefi-secure-boot.rst
> new file mode 100644
> index 000000000000..0e0f50143892
> --- /dev/null
> +++ b/docs/admin-guide/uefi-secure-boot.rst
> @@ -0,0 +1,134 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +UEFI Secure Boot
> +================
> +
> +UEFI Secure Boot is a verification mechanism, intended to ensure that only
> +code trusted by the platform can run.  This is to prevent malicious code from
> +hijacking the system.  Secure Boot requires that all privileged code be
> +signed, and that there is a trust relationship with the platform; i.e. code
> +which is not signed by a key enrolled in platform must not run privileged.
> +
> +Within the Xen architecture, Xen, the :term:`control domain` and
> +:term:`hardware domain` share responsibility for running and administering the
> +platform.  This makes their kernels privileged as far as Secure Boot is
> +concerned.
> +
> +When Secure Boot is active in the platform, privileged code is required to not
> +run any untrusted code (i.e. not run any code for which there is not a good
> +signature), and is required not to allow this restriction to be bypassed
> +(e.g. by command line request).
> +
> +
> +Support in Xen
> +--------------
> +
> +There are multiple ways to achieve this security goal, with differing
> +tradeoffs for the eventual system.
> +
> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
> +livepatching and kexec compiled out, and suitably signed.  The signature is
> +checked by the bootloader and, as this covers all the privileged code, Xen
> +doesn't need to perform further checks itself.
> +
> +On the other end of the spectrum is maintaining the features of existing
> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
> +command line options while disallowing unsafe ones.

I just wanted to mention that there is one more option which I used in
the past: the firmware/bootloader loads Xen, the Dom0 kernel, and other
binaries, check their signatures, then boot Xen.

This is similar to the "Unified Kernel Image" approach in the sense that
Xen doesn't need to do any signature checking for the dom0 kernel, but
it doesn't require all the binaries to be glued together.

Assuming that the firmware/bootloader is capable of loading multiple
binaries and checking the signature of multiple binaries before booting
the next element, it works fine.



> +It is important to remember that Xen is one piece of the larger platform,
> +where every piece depends on the correct functioning of all earlier pieces.  A
> +product supporting Secure Boot requires a holistic approach involving all
> +components in the system.  It is not sufficient to consider Xen in isolation.
> +
> +.. TODO: Move "In Progress" tasks here as they become ready
> +
> +Security Scope
> +--------------
> +
> +Vulnerabilities impacting Secure Boot require a fixed component to be produced
> +and distributed, the vulnerable component to be revoked, and the revocation
> +distributed to platforms.
> +
> +The following principles and guidelines indicate where Secure Boot differs
> +from more traditional security models, and the situations in which extra
> +remediation may be necessary.
> +
> +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.
> +
> + * Root or ADMIN in userspace is unprivileged from Secure Boot's point of
> +   view, and must not be able to alter the enforcement policy or load unsigned
> +   code even by e.g. editing a configuration file and rebooting.
> +
> +Within Scope
> +^^^^^^^^^^^^
> +
> +The following types of issue require remediation and revocation of vulnerable
> +binaries.
> +
> + * Any failure to apply enforcements even against traditionally-privileged
> +   userspace, including failure to authenticate new code to run and failure to
> +   handle revocations properly.
> +
> + * Any Out-of-Bounds write capable of altering the enforcement policy, or
> +   capable of bypassing enforcement, e.g. by corrupting the running code.
> +
> +Out of Scope
> +^^^^^^^^^^^^
> +
> +While typically a security issue in their own rights, these issues do not
> +constitute a Secure Boot vulnerability, and do not require special
> +remediation.
> +
> + * Denial of Service vulnerabilities.
> +
> + * Out-of-Bounds reads.
> +
> +The Xen Security Team will endeavour to produce XSAs for all violations of
> +this security policy, including identifying them specifically as requiring
> +further remediation by downstreams.
> +
> +
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.
> +
> +
> +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
> -- 
> 2.39.5
> 

On 12.06.2025 23:32, Stefano Stabellini wrote:
> On Thu, 12 Jun 2025, Andrew Cooper wrote:
>> +Support in Xen
>> +--------------
>> +
>> +There are multiple ways to achieve this security goal, with differing
>> +tradeoffs for the eventual system.
>> +
>> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
>> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
>> +livepatching and kexec compiled out, and suitably signed.  The signature is
>> +checked by the bootloader and, as this covers all the privileged code, Xen
>> +doesn't need to perform further checks itself.
>> +
>> +On the other end of the spectrum is maintaining the features of existing
>> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
>> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
>> +command line options while disallowing unsafe ones.
> 
> I just wanted to mention that there is one more option which I used in
> the past: the firmware/bootloader loads Xen, the Dom0 kernel, and other
> binaries, check their signatures, then boot Xen.
> 
> This is similar to the "Unified Kernel Image" approach in the sense that
> Xen doesn't need to do any signature checking for the dom0 kernel, but
> it doesn't require all the binaries to be glued together.
> 
> Assuming that the firmware/bootloader is capable of loading multiple
> binaries and checking the signature of multiple binaries before booting
> the next element, it works fine.

How would an initrd, a ucode blob, or an XSM policy blob be signed?

Jan

On Fri, Jun 13, 2025 at 08:35:26AM +0200, Jan Beulich wrote:
> On 12.06.2025 23:32, Stefano Stabellini wrote:
> > On Thu, 12 Jun 2025, Andrew Cooper wrote:
> >> +Support in Xen
> >> +--------------
> >> +
> >> +There are multiple ways to achieve this security goal, with differing
> >> +tradeoffs for the eventual system.
> >> +
> >> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
> >> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
> >> +livepatching and kexec compiled out, and suitably signed.  The signature is
> >> +checked by the bootloader and, as this covers all the privileged code, Xen
> >> +doesn't need to perform further checks itself.
> >> +
> >> +On the other end of the spectrum is maintaining the features of existing
> >> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
> >> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
> >> +command line options while disallowing unsafe ones.
> > 
> > I just wanted to mention that there is one more option which I used in
> > the past: the firmware/bootloader loads Xen, the Dom0 kernel, and other
> > binaries, check their signatures, then boot Xen.
> > 
> > This is similar to the "Unified Kernel Image" approach in the sense that
> > Xen doesn't need to do any signature checking for the dom0 kernel, but
> > it doesn't require all the binaries to be glued together.
> > 
> > Assuming that the firmware/bootloader is capable of loading multiple
> > binaries and checking the signature of multiple binaries before booting
> > the next element, it works fine.
> 
> How would an initrd, a ucode blob, or an XSM policy blob be signed?

At least grub supports gpg detached signatures, and can be configured to
require them.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

On Fri, 13 Jun 2025, Marek Marczykowski-Górecki wrote:
> On Fri, Jun 13, 2025 at 08:35:26AM +0200, Jan Beulich wrote:
> > On 12.06.2025 23:32, Stefano Stabellini wrote:
> > > On Thu, 12 Jun 2025, Andrew Cooper wrote:
> > >> +Support in Xen
> > >> +--------------
> > >> +
> > >> +There are multiple ways to achieve this security goal, with differing
> > >> +tradeoffs for the eventual system.
> > >> +
> > >> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
> > >> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
> > >> +livepatching and kexec compiled out, and suitably signed.  The signature is
> > >> +checked by the bootloader and, as this covers all the privileged code, Xen
> > >> +doesn't need to perform further checks itself.
> > >> +
> > >> +On the other end of the spectrum is maintaining the features of existing
> > >> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
> > >> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
> > >> +command line options while disallowing unsafe ones.
> > > 
> > > I just wanted to mention that there is one more option which I used in
> > > the past: the firmware/bootloader loads Xen, the Dom0 kernel, and other
> > > binaries, check their signatures, then boot Xen.
> > > 
> > > This is similar to the "Unified Kernel Image" approach in the sense that
> > > Xen doesn't need to do any signature checking for the dom0 kernel, but
> > > it doesn't require all the binaries to be glued together.
> > > 
> > > Assuming that the firmware/bootloader is capable of loading multiple
> > > binaries and checking the signature of multiple binaries before booting
> > > the next element, it works fine.
> > 
> > How would an initrd, a ucode blob, or an XSM policy blob be signed?
> 
> At least grub supports gpg detached signatures, and can be configured to
> require them.

That's right. U-boot supports something similar as well.

On 12/06/2025 02:03, Andrew Cooper wrote:
> Written to be solution and deployment neutral in order to focus on the
> technology itself.  This policy is intended to work as well for UKI as for the
> "classic server setup" approach.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: security@xen.org
> CC: Juergen Gross <jgross@suse.com>
> CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> CC: Trammell Hudson <hudson@trmm.net>
> CC: Ross Lagerwall <ross.lagerwall@cloud.com>
> CC: Frediano Ziglio <frediano.ziglio@cloud.com>
> CC: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
> CC: Kevin Lampis <kevin.lampis@cloud.com>
> 
> A rendered version is available at:
>    https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html
> 
> 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.
> 
> 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().
> 

As I understand it, hardware attacks currently don't count in the Secure 
Boot security model, and it would only depend on whether userspace code 
can use the vulnerability to run privileged code right?

> 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.
> 
> 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.
> ---
>   docs/admin-guide/index.rst            |   1 +
>   docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++
>   2 files changed, 135 insertions(+)
>   create mode 100644 docs/admin-guide/uefi-secure-boot.rst
> 
> diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
> index 54e6f65de347..e7895ee95001 100644
> --- a/docs/admin-guide/index.rst
> +++ b/docs/admin-guide/index.rst
> @@ -5,4 +5,5 @@ Admin Guide
>   
>   .. toctree::
>      introduction
> +   uefi-secure-boot
>      microcode-loading
> diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/uefi-secure-boot.rst
> new file mode 100644
> index 000000000000..0e0f50143892
> --- /dev/null
> +++ b/docs/admin-guide/uefi-secure-boot.rst
> @@ -0,0 +1,134 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +UEFI Secure Boot
> +================
> +
> +UEFI Secure Boot is a verification mechanism, intended to ensure that only
> +code trusted by the platform can run.  This is to prevent malicious code from
> +hijacking the system.  Secure Boot requires that all privileged code be
> +signed, and that there is a trust relationship with the platform; i.e. code
> +which is not signed by a key enrolled in platform must not run privileged.
> +
> +Within the Xen architecture, Xen, the :term:`control domain` and
> +:term:`hardware domain` share responsibility for running and administering the
> +platform.  This makes their kernels privileged as far as Secure Boot is
> +concerned.
> +
> +When Secure Boot is active in the platform, privileged code is required to not
> +run any untrusted code (i.e. not run any code for which there is not a good
> +signature), and is required not to allow this restriction to be bypassed
> +(e.g. by command line request).
> +
> +
> +Support in Xen
> +--------------
> +
> +There are multiple ways to achieve this security goal, with differing
> +tradeoffs for the eventual system.
> +
> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
> +livepatching and kexec compiled out, and suitably signed.  The signature is
> +checked by the bootloader and, as this covers all the privileged code, Xen
> +doesn't need to perform further checks itself.
> +
> +On the other end of the spectrum is maintaining the features of existing
> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
> +command line options while disallowing unsafe ones.
> +
> +It is important to remember that Xen is one piece of the larger platform,
> +where every piece depends on the correct functioning of all earlier pieces.  A
> +product supporting Secure Boot requires a holistic approach involving all
> +components in the system.  It is not sufficient to consider Xen in isolation.
> +
> +.. TODO: Move "In Progress" tasks here as they become ready
> +
> +Security Scope
> +--------------
> +
> +Vulnerabilities impacting Secure Boot require a fixed component to be produced
> +and distributed, the vulnerable component to be revoked, and the revocation
> +distributed to platforms.
> +
> +The following principles and guidelines indicate where Secure Boot differs
> +from more traditional security models, and the situations in which extra
> +remediation may be necessary.
> +
> +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.
> +
> + * Root or ADMIN in userspace is unprivileged from Secure Boot's point of
> +   view, and must not be able to alter the enforcement policy or load unsigned
> +   code even by e.g. editing a configuration file and rebooting.
> +
> +Within Scope
> +^^^^^^^^^^^^
> +
> +The following types of issue require remediation and revocation of vulnerable
> +binaries.
> +
> + * Any failure to apply enforcements even against traditionally-privileged
> +   userspace, including failure to authenticate new code to run and failure to
> +   handle revocations properly.
> +
> + * Any Out-of-Bounds write capable of altering the enforcement policy, or
> +   capable of bypassing enforcement, e.g. by corrupting the running code.
> +
> +Out of Scope
> +^^^^^^^^^^^^
> +
> +While typically a security issue in their own rights, these issues do not
> +constitute a Secure Boot vulnerability, and do not require special
> +remediation.
> +
> + * Denial of Service vulnerabilities.
> +
> + * Out-of-Bounds reads.
> +
> +The Xen Security Team will endeavour to produce XSAs for all violations of
> +this security policy, including identifying them specifically as requiring
> +further remediation by downstreams.
> +
> +
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.
> +
> +
> +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.
> +

Why would Xen not maintain its own SBAT generation? An upstream SBAT 
incremented for every Secure Boot bypass XSA would make it far easier to 
block vulnerable variants and help downstreams coordinate fixes.

> +
> +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

IMO key management, signing and revocation should be another topic for a 
TODO element.

Best regards,



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

On 12.06.2025 15:15, Tu Dinh wrote:
> On 12/06/2025 02:03, Andrew Cooper wrote:
>> +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.
>> +
> 
> Why would Xen not maintain its own SBAT generation? An upstream SBAT 
> incremented for every Secure Boot bypass XSA would make it far easier to 
> block vulnerable variants and help downstreams coordinate fixes.

Quoting from the SBAT patch that was submitted a little while ago:

"The SBAT section provides a way for the binary to declare a generation
 id for its upstream source and any vendor changes applied."

That is, the generation ID is per-vendor. Upstream incrementing whatever
ID would be meaningless to downstreams then. Hence we can as well not do
so in the first place.

Jan

On 12/06/2025 15:22, Jan Beulich wrote:
> On 12.06.2025 15:15, Tu Dinh wrote:
>> On 12/06/2025 02:03, Andrew Cooper wrote:
>>> +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.
>>> +
>>
>> Why would Xen not maintain its own SBAT generation? An upstream SBAT
>> incremented for every Secure Boot bypass XSA would make it far easier to
>> block vulnerable variants and help downstreams coordinate fixes.
> 
> Quoting from the SBAT patch that was submitted a little while ago:
> 
> "The SBAT section provides a way for the binary to declare a generation
>   id for its upstream source and any vendor changes applied."
> 
> That is, the generation ID is per-vendor. Upstream incrementing whatever
> ID would be meaningless to downstreams then. Hence we can as well not do
> so in the first place.
> 
> Jan

Don't Shim, Grub and Linux all have their own upstream SBAT generation? 
The Shim SBAT documentation explicitly pointed this out:

 > Each component is assigned a minimum global generation number. 
Vendors signing component binary artifacts with a specific global 
generation number are required to include fixes for any public or 
pre-disclosed issue required for that generation. Additionally, in the 
event that a bypass only manifests in a specific product's component, 
vendors may ask for a product-specific generation number to be published 
for one of their product's components. This avoids triggering an 
industry wide re-publishing of otherwise safe components.

IOW Xen should have its own upstream generation ID for any vulnerability 
that leads to a Secure Boot bypass. Any vendor that patches such a 
vulnerability can simply increase the upstream generation ID it carries 
in its SBAT to that of the latest Xen. Then any inferior upstream 
generation can simply be revoked to cover all vendors at once.

Best regards,


Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

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

On 6/12/25 06:06, Jan Beulich wrote:
> On 12.06.2025 01:58, Andrew Cooper wrote:
>> 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?

Dasharo supports leaving the IOMMU enabled when transferring to the OS, and
this message was sent from a Qubes OS box booted in this configuration.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

On Thu, Jun 12, 2025 at 11:22:39AM -0400, Demi Marie Obenour wrote:
> On 6/12/25 06:06, Jan Beulich wrote:
> > On 12.06.2025 01:58, Andrew Cooper wrote:
> >> 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?
> 
> Dasharo supports leaving the IOMMU enabled when transferring to the OS, and
> this message was sent from a Qubes OS box booted in this configuration.

"Not explode" doesn't mean it "works" or is "supported". For example
there is no guarantee that IOMMU don't get disabled in the process
opening a window for an attack. (and I do know this issue is the case)

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

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).

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

On Thu, Jun 12, 2025 at 1:21 PM Teddy Astie <teddy.astie@vates.tech> 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

On Thu, Jun 12, 2025 at 12:58:51AM +0100, Andrew Cooper wrote:
> Written to be solution and deployment neutral in order to focus on the
> technology itself.  This policy is intended to work as well for UKI as for the
> "classic server setup" approach.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: security@xen.org
> CC: Juergen Gross <jgross@suse.com>
> CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> CC: Trammell Hudson <hudson@trmm.net>
> CC: Ross Lagerwall <ross.lagerwall@cloud.com>
> CC: Frediano Ziglio <frediano.ziglio@cloud.com>
> CC: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
> CC: Kevin Lampis <kevin.lampis@cloud.com>
> 
> A rendered version is available at:
>   https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html
> 
> 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.

Should there be some guidelines what values are/aren't safe for UEFI SB?
I don't think there can be a simple list, for example some things may
depend on other settings and/or whether UKI is involved. But some
comment about relation to UEFI SB (in Kconfig help?) would be useful.
As for CONFIG_CMDLINE, IIUC the current implementation does cover it too
(as in, lockdown mode will filter built-in cmdline too).

> 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().

That's a very good question. Do you know if disabling pre-boot DMA
protection is allowed if UEFI SB is enabled? If so, I'd assume it
doesn't need to be covered.

> 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.
> 
> 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.
> ---
>  docs/admin-guide/index.rst            |   1 +
>  docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++
>  2 files changed, 135 insertions(+)
>  create mode 100644 docs/admin-guide/uefi-secure-boot.rst
> 
> diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
> index 54e6f65de347..e7895ee95001 100644
> --- a/docs/admin-guide/index.rst
> +++ b/docs/admin-guide/index.rst
> @@ -5,4 +5,5 @@ Admin Guide
>  
>  .. toctree::
>     introduction
> +   uefi-secure-boot
>     microcode-loading
> diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/uefi-secure-boot.rst
> new file mode 100644
> index 000000000000..0e0f50143892
> --- /dev/null
> +++ b/docs/admin-guide/uefi-secure-boot.rst
> @@ -0,0 +1,134 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +UEFI Secure Boot
> +================
> +
> +UEFI Secure Boot is a verification mechanism, intended to ensure that only
> +code trusted by the platform can run.  This is to prevent malicious code from
> +hijacking the system.  Secure Boot requires that all privileged code be
> +signed, and that there is a trust relationship with the platform; i.e. code
> +which is not signed by a key enrolled in platform must not run privileged.
> +
> +Within the Xen architecture, Xen, the :term:`control domain` and
> +:term:`hardware domain` share responsibility for running and administering the
> +platform.  This makes their kernels privileged as far as Secure Boot is
> +concerned.
> +
> +When Secure Boot is active in the platform, privileged code is required to not
> +run any untrusted code (i.e. not run any code for which there is not a good
> +signature), and is required not to allow this restriction to be bypassed
> +(e.g. by command line request).
> +
> +
> +Support in Xen
> +--------------
> +
> +There are multiple ways to achieve this security goal, with differing
> +tradeoffs for the eventual system.
> +
> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
> +livepatching and kexec compiled out, and suitably signed.  The signature is
> +checked by the bootloader and, as this covers all the privileged code, Xen
> +doesn't need to perform further checks itself.
> +
> +On the other end of the spectrum is maintaining the features of existing
> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
> +command line options while disallowing unsafe ones.
> +
> +It is important to remember that Xen is one piece of the larger platform,
> +where every piece depends on the correct functioning of all earlier pieces.  A
> +product supporting Secure Boot requires a holistic approach involving all
> +components in the system.  It is not sufficient to consider Xen in isolation.

This paragraph is a bit vague. Maybe include (repeat) that it includes
any privileged domain's kernel, but also bootloader(s)? Or simply remove
it as it doesn't add much give the introduction section explaining this
already.

> +
> +.. TODO: Move "In Progress" tasks here as they become ready
> +
> +Security Scope
> +--------------
> +
> +Vulnerabilities impacting Secure Boot require a fixed component to be produced
> +and distributed, the vulnerable component to be revoked, and the revocation
> +distributed to platforms.
> +
> +The following principles and guidelines indicate where Secure Boot differs
> +from more traditional security models, and the situations in which extra
> +remediation may be necessary.
> +
> +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.
> +
> + * Root or ADMIN in userspace is unprivileged from Secure Boot's point of
> +   view, and must not be able to alter the enforcement policy or load unsigned
> +   code even by e.g. editing a configuration file and rebooting.
> +
> +Within Scope
> +^^^^^^^^^^^^
> +
> +The following types of issue require remediation and revocation of vulnerable
> +binaries.
> +
> + * Any failure to apply enforcements even against traditionally-privileged
> +   userspace, including failure to authenticate new code to run and failure to
> +   handle revocations properly.
> +
> + * Any Out-of-Bounds write capable of altering the enforcement policy, or
> +   capable of bypassing enforcement, e.g. by corrupting the running code.
> +
> +Out of Scope
> +^^^^^^^^^^^^
> +
> +While typically a security issue in their own rights, these issues do not
> +constitute a Secure Boot vulnerability, and do not require special
> +remediation.
> +
> + * Denial of Service vulnerabilities.
> +
> + * Out-of-Bounds reads.

Maybe more generic "Information disclosure" or "Information leak"?

> +
> +The Xen Security Team will endeavour to produce XSAs for all violations of
> +this security policy, including identifying them specifically as requiring
> +further remediation by downstreams.
> +
> +
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.
> +
> +
> +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
> -- 
> 2.39.5
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

On 12.06.2025 09:50, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 12, 2025 at 12:58:51AM +0100, Andrew Cooper wrote:
>> 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.
> 
> Should there be some guidelines what values are/aren't safe for UEFI SB?
> I don't think there can be a simple list, for example some things may
> depend on other settings and/or whether UKI is involved. But some
> comment about relation to UEFI SB (in Kconfig help?) would be useful.
> As for CONFIG_CMDLINE, IIUC the current implementation does cover it too
> (as in, lockdown mode will filter built-in cmdline too).

For command line options I think the doc ought to include some form of
annotation, at least in one direction (permitted or not permitted).

For Kconfig it's less clear to me what an "insecure default" could be.

Jan

On 6/11/25 19:58, Andrew Cooper wrote:
> Written to be solution and deployment neutral in order to focus on the
> technology itself.  This policy is intended to work as well for UKI as for the
> "classic server setup" approach.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: security@xen.org
> CC: Juergen Gross <jgross@suse.com>
> CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> CC: Trammell Hudson <hudson@trmm.net>
> CC: Ross Lagerwall <ross.lagerwall@cloud.com>
> CC: Frediano Ziglio <frediano.ziglio@cloud.com>
> CC: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
> CC: Kevin Lampis <kevin.lampis@cloud.com>
> 
> A rendered version is available at:
>   https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html
> 
> 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.
> 
> 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().
> 
> 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.
> 
> 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.
> ---
>  docs/admin-guide/index.rst            |   1 +
>  docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++
>  2 files changed, 135 insertions(+)
>  create mode 100644 docs/admin-guide/uefi-secure-boot.rst
> 
> diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
> index 54e6f65de347..e7895ee95001 100644
> --- a/docs/admin-guide/index.rst
> +++ b/docs/admin-guide/index.rst
> @@ -5,4 +5,5 @@ Admin Guide
>  
>  .. toctree::
>     introduction
> +   uefi-secure-boot
>     microcode-loading
> diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/uefi-secure-boot.rst
> new file mode 100644
> index 000000000000..0e0f50143892
> --- /dev/null
> +++ b/docs/admin-guide/uefi-secure-boot.rst
> @@ -0,0 +1,134 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +UEFI Secure Boot
> +================
> +
> +UEFI Secure Boot is a verification mechanism, intended to ensure that only
> +code trusted by the platform can run.  This is to prevent malicious code from
> +hijacking the system.  Secure Boot requires that all privileged code be
> +signed, and that there is a trust relationship with the platform; i.e. code
> +which is not signed by a key enrolled in platform must not run privileged.
> +
> +Within the Xen architecture, Xen, the :term:`control domain` and
> +:term:`hardware domain` share responsibility for running and administering the
> +platform.  This makes their kernels privileged as far as Secure Boot is
> +concerned.
> +
> +When Secure Boot is active in the platform, privileged code is required to not
> +run any untrusted code (i.e. not run any code for which there is not a good
> +signature), and is required not to allow this restriction to be bypassed
> +(e.g. by command line request).
> +
> +
> +Support in Xen
> +--------------
> +
> +There are multiple ways to achieve this security goal, with differing
> +tradeoffs for the eventual system.
> +
> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
> +livepatching and kexec compiled out, and suitably signed.  The signature is
> +checked by the bootloader and, as this covers all the privileged code, Xen
> +doesn't need to perform further checks itself.
> +
> +On the other end of the spectrum is maintaining the features of existing
> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
> +command line options while disallowing unsafe ones.
> +
> +It is important to remember that Xen is one piece of the larger platform,
> +where every piece depends on the correct functioning of all earlier pieces.  A
> +product supporting Secure Boot requires a holistic approach involving all
> +components in the system.  It is not sufficient to consider Xen in isolation.
> +
> +.. TODO: Move "In Progress" tasks here as they become ready
> +
> +Security Scope
> +--------------
> +
> +Vulnerabilities impacting Secure Boot require a fixed component to be produced
> +and distributed, the vulnerable component to be revoked, and the revocation
> +distributed to platforms.
> +
> +The following principles and guidelines indicate where Secure Boot differs
> +from more traditional security models, and the situations in which extra
> +remediation may be necessary.
> +
> +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.
> +
> + * Root or ADMIN in userspace is unprivileged from Secure Boot's point of
> +   view, and must not be able to alter the enforcement policy or load unsigned
> +   code even by e.g. editing a configuration file and rebooting.
> +
> +Within Scope
> +^^^^^^^^^^^^
> +
> +The following types of issue require remediation and revocation of vulnerable
> +binaries.
> +
> + * Any failure to apply enforcements even against traditionally-privileged
> +   userspace, including failure to authenticate new code to run and failure to
> +   handle revocations properly.
> +
> + * Any Out-of-Bounds write capable of altering the enforcement policy, or
> +   capable of bypassing enforcement, e.g. by corrupting the running code.
> +
> +Out of Scope
> +^^^^^^^^^^^^
> +
> +While typically a security issue in their own rights, these issues do not
> +constitute a Secure Boot vulnerability, and do not require special
> +remediation.
> +
> + * Denial of Service vulnerabilities.
> +
> + * Out-of-Bounds reads.
> +
> +The Xen Security Team will endeavour to produce XSAs for all violations of
> +this security policy, including identifying them specifically as requiring
> +further remediation by downstreams.
> +
> +
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.
> +
> +
> +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

This is so much more reasonable than Linux's policy.  I wonder how often Linux
would need to revoke if it followed a policy like this.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)