On 06/08/2025 5:55 pm, Andrew Cooper wrote: > A toolstack is expected to use XEN_DOMCTL_hypercall_init where applicable to > construct a new guest, but is absolutely not expected to use it against > itself. Kernels have a stable ABI for accessing the same functionality, via > MSR 0x40000000. > > Found when auditing hypercalls for Host UEFI-SecureBoot safety. > > Reported-by: Frediano Ziglio <frediano.zig...@cloud.com> > 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: Ross Lagerwall <ross.lagerw...@citrix.com> > CC: Frediano Ziglio <frediano.zig...@cloud.com>
It's worth nothing that the observations which lead to this mean it's impossible to support multiple TCB domains without Flask. Imagine that we did have two control domains and they could operate on each other. It's inappropriate for the domain's kernel to be auditing which domid's are which privilege. Flask can let Xen express that level of control, and in practice the system would need configuring with a privilege hierarchy. Equally-powerful domains which can operate on each other simply doesn't make sense from a system point of view. But, as Flask is not supported yet in Xen, the Host UEFI-SB security policy is going to have to be limited to a single all-power dom0 in the short term. ~Andrew
