On Tue, 22 Apr 2025 at 20:17, Andrew Cooper <andrew.coop...@citrix.com> wrote: > > On 21/04/2025 9:52 pm, Dave Hansen wrote: > > Purely from the amount of interest and review tags and the whole "v14" > > thing, it doesn't look like this is very important to anyone. Not to be > > to flippant about it, but if nobody else cares, why should I (or the > > other x86 maintainers)? > > There are several downstreams already using this as a part of their > overall system security, one example being > https://www.qubes-os.org/doc/anti-evil-maid/ > > It's all giant out-of-tree patch series (in multiple projects; Grub, > Xen, iPXE too).
... and this is the main problem: All the existing protocols and layering go straight out the window, and are replaced with bespoke alternatives, for booting but also for secondary bringup, etc etc Conceptually, the secure launch could be performed under the hood, e.g., during ExitBootServices() when doing EFI boot, and the OS would have to be none the wiser (or at least, not need 100s of additional lines of opaque assembly to be able to operate in this mode). The fact that all these components need such intrusive changes in order to orchestrate this pivot to the reduced TCB constitutes a spectacular failure in design IMO, but AIUI, the software side is not really at fault here: the layering violations are intrinsic to the hardware support in the CPU. I'm sure Andy or others on cc can elaborate on this, as they have done many times already. So if that is true (I'm not a x86 uarch expert by any measure), then pushing back on this series on the basis that it is ugly and intrusive is not really reasonable. From security pov, I think D-RTM is an important feature and it deserves to be upstream if it is used widely in the field. OTOH, if the arm64 implementation (which is still on the drawing board) bears any resemblance at all to the x86 version, it can be considered NACKed already.
