Re: [RFC] efi/boot: Unified Xen executable for UEFI Secure Boot support

[Trammell Hudson <hudson@xxxxxxxx>]

On Thursday, August 6, 2020 8:14 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
wrote:
> For SecureBoot, it is important that nothing which is signed can be
> tricked into running unsigned code.
>
> That includes configuration such as xen.cfg or the command line.
> Consuming these from unsigned sources is ok, so long as we can guarantee
> that the parsing is robust (see boothole for how this goes wrong), and
> the effects are controlled.

In addition to the "unsafe_fsgsbase", the Linux command line is full
of potential issues, from subtle ones like "lockdown=none" to more
brute force things like "init=/bin/sh".  safeboot uses the signed
kernel command line to pass in the root hash of the dm-verity Merkle
tree, which cryptographically protects the rest of the runtime, so
it definitely needs to come from a trusted source.

> [...]
> In the absence of a full audit of all our command line arguments, and
> extra vigilance reviewing code coming in, the safer alternative is to
> prohibit use of the command line, and only accept it in its Kconfig
> embedded form for now.

Turning off command line or config parsing might be a step too far.
Since the xen.cfg in the unified image is included in the signature,
any options configured in it should be trustworthy.  This makes it easier
for distributions to have a Xen build with boot-time work arounds for
different hardware or configurations.

> [...]
> I think it might be worth having a CONFIG_SECURE_BOOT, selectable
> initially only under CONFIG_EXPERT, and use it to force off various
> other aspects of functionality, along with a list of known issues which
> can be chipped away at before it can be declared supported.

That makes sense to me.  Either doing it at compile time (by making
CONFIG_LIVEPATCH and CONFIG_KEXEC and etc depend on !CONFIG_SECURE_BOOT),
or having a global variable that turns off the code (similar to the
Linux lockdown patches that are triggered if UEFI secure boot is enabled).

> [...]
> I think it is great that work is being started in this direction, but
> there is a huge quantity of work to do before a downstream could
> plausibly put together a Xen system which honours the intent of SecureBoot.

I'm really worried that the current shim based approach is a false sense
of security -- it provides trivial ways for attackers to bypass the
SecureBoot guarantees, so closing some of those easy holes with the
verified unified image is definitely an incremental improvement towards
a more secure system.

However, I also don't want the unified image patch to get bogged down
while trying to pursue every UEFI SecureBoot(tm) related issue, so
perhaps the patch series should be renamed to only focus on the unified
build part, not the SecureBoot part.  That way downstream distributions
can use it to add the security features that they need (caveat lector),
without necessarily depending on the strict UEFI compliance.

--
Trammell