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.coop...@citrix.com> > --- > CC: Anthony PERARD <anthony.per...@vates.tech> > CC: Michal Orzel <michal.or...@amd.com> > CC: Jan Beulich <jbeul...@suse.com> > CC: Julien Grall <jul...@xen.org> > CC: Roger Pau Monné <roger....@citrix.com> > CC: Stefano Stabellini <sstabell...@kernel.org> > CC: secur...@xen.org > CC: Juergen Gross <jgr...@suse.com> > CC: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> > CC: Trammell Hudson <hud...@trmm.net> > CC: Ross Lagerwall <ross.lagerw...@cloud.com> > CC: Frediano Ziglio <frediano.zig...@cloud.com> > CC: Gerald Elder-Vass <gerald.elder-v...@cloud.com> > CC: Kevin Lampis <kevin.lam...@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)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
