Re: [PATCH v14 00/19] x86: Trenchboot secure dynamic launch Linux kernel support

Ard Biesheuvel
2025-04-22T21:26:48Z

On Tue, 22 Apr 2025 at 20:17, Andrew Cooper <andrew.cooper3@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.