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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/08/2020 19:22, Trammell Hudson wrote:
> 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".

Oh - of course.  That one is far easier.

>   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.

Apologies - I didn't mean to suggest disabling command line parsing
entirely.  Simply from unsigned sources.

With the proposal here, there are two signed sources; one in Kconfig,
and one in the embedded xen.cfg file.

>
>> [...]
>> 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).

Hmm - I'm in two minds here.

>From a user point of view, we really don't want it to be compile-time
only, because it is very important to be able to debug the exact binary
which is giving you problems, and some times that will mean "disable
secure boot and poke".

On the other hand, simply putting a "Secure Boot Enabled" check/print in
there will probably (at this point) give users a false sense of any of
this being remotely supported.

>> [...]
>> 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.

Its entirely fine to take incremental work.  I didn't mean to give the
impression of objecting to this change just because it wasn't fully UEFI
SecureBoot(tm) compliant.

My main concern is simply to avoid giving any kind of impression that
UEFI SecureBoot is generally usable at the moment.

~Andrew