Xen Summit 2025 - "Secure boot lockdown" design discussion notes

[Alex Brett <alex.brett@xxxxxxxxxx>]

SBAT summary: Upstream Xen will not maintain a generation number, but will 
publish recommendations as to whether downstreams should bump theirs in XSAs 
etc.

Lockdown: No patches currently merged.

Andrew Cooper (AC): Done initial secure boot policy document, needs refreshing 
to bring up to date and reposting. *ACTION*
Jan Beulich (JB): Document should be able to go in even close to the release.
Oleksii Kurochko (OK): No issue with that :)

AC: Document is trying to state the security boundary. Get this merged, then 
patch series will also include moving things from In Progress to now set in 
stone as appropriate. Document is used to define the judgement the security 
team will apply when considering if an issue is security or whether it impacts 
SBAT etc.

AC: With this in place, it feeds in to the design for lockdown in particular. 
Lockdown named after Linux way of doing it, just a name (though hate it but 
can't think of a better one). Idea is if you boot in secure more it's forced 
on, but want the ability to turn it on even without secure boot (for testing / 
ensuring you don't introduce things which are relying on it not being present 
etc). Framing lockdown mode like this does change quite a few of the 
discussions around e.g. command line parsing order etc.

AC: Can say if a developer is using it for testing purposes, they should 
understand command line is parsed L-R and should therefore put lockdown option 
early etc.
Yann Sionneau (YS): Need to ensure we don't allow lockdown mode to be disabled 
when using secure boot (AC: that would be a security issue and need bumping 
SBAT etc).

JB: Lockdown mode outside of secure boot primarily for developers.

AC: Don't want to worry about having to do multiple scans of command line etc 
(for outside of secure boot enabled), as command line comes from multiple 
places etc. Trust developer to put it in the right place.

JB: How do we deal with something on the built in command line that's not 
permitted with lockdown?
AC: Should be allowed
JB: What about in secure boot mode?
AC: Good point - might need to pass a flag in

Marek Marczykowski-Górecki (MM): In the unified image should the command line 
there be permitted to bypass lockdown options?
AC: Yes, the command line is part of the signed image etc at that point.

MM: Should add a CI job with lockdown enabled. *ACTION*
AC: Yes, in the Trixie containers we're now far more amenable to testing these 
things. There's an OVMF ROM that has secure boot forced on along with the 
private key to sign the test image that should enable doing this.

YS: Is there a security issue if a command line in a unified image disables 
lockdown?
JB: We wouldn't have an option for lockdown off, only to turn it on
AC: If as a downstream you sign an image that disables security, that's your 
fault and you've got a security vulnerability. We can't always prevent people 
shooting themselves in the foot.

AC: In principal any binary that has had a signature check is in principal 
good, even if it does things that wouldn't be allowed in a runtime command line 
argument.
JB: If someone signs something with a wrong option, that's not Xen's fault and 
not a security bug in Xen.
YS: Agreed, but could we put code that shouldn't allow things to go in to an 
insecure mode if secure boot is enabled?
AC: Gave an example of a HAP superpage option, which wasn't in the list of 
allowed options so was ignored by Xen (but is safe to change) - being able to 
embed that in a built-in command line makes sense.

Daniel Smith (DS): At the end of the day Xen doesn't want to be in the business 
of dictating to its users what's safe or not
AC: Gave an example of COM port options that are in most cases safe but IO base 
can allow a vulnerability. For some of the more complicated options it will be 
difficult to know what's safe or not, so giving downstreams the ability to 
declare its safe and run with it is needed.

privcmd
Alex Brett (AB) (on behalf of Ross Lagerwall (RL)): For lockdown of privcmd, 
the only part we think needs fixing is the raw hypercall access 
(IOCTL_PRIVCMD_HYPERCALL). In XenServer, we have done this using an additional 
filtering layer. This is not something we want to upstream since it binds the 
kernel to a specific Xen ABI. Instead, we want to introduce a new stable 
hypercall ABI that allows the kernel to filter in a generic way (much like 
dm_op). We haven't scheduled the work to do this.

AC: Explained that it's the guest kernel which needs to decide what userspace 
can and can't do to send hypercalls. In Linux secure boot requires you to call 
access ok on every pointer or memory range etc. The new ABI in Xen would allow 
the kernel to do this without having to know about the Xen structure, by 
guaranteeing there are no pointers in it.

AC: You have hypercalls that are safe, and ones that are not. With privcmd 
currently userspace can violate all kernel lockdown protections, so need to 
ensure the unsafe hypercalls can only be issued by the kernel. Fine for the 
kernel to offer e.g. /dev/xen/eventchn as the kernel is mediating the access.

AC: One thing to do in the document is to go through hypercalls and subops and 
classify if they're logically a privileged command or a control plane command. 
This gives the separation of what's strictly kernel only/mediated, vs things a 
kernel wouldn't care about. *ACTION*

AC: Other issues, e.g. toolstack uses eventchn_op targetting a new domain, but 
this would ideally be a domctl op.

AC: Reason we said secure boot v1 will only allow a monolithic dom0 is 
otherwise one privileged domain could target the other and violate specs. Also 
need to make sure certain operations can't be performed on yourself.

AC: The XenServer filtering code (which will be released, just not upstreamed) 
is a good starting point for what needs looking at. Fits into the wider API/ABI 
plans.
AC: The XenServer code is a stop gap to be able to ship (and hopefully get 
through the API/ABI community).