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

[Trammell Hudson <hudson@xxxxxxxx>]

[ Responding to both Jan and Andrew's comments about config parsing
and file sources when secure boot is enabled ]

On Friday, August 7, 2020 2:23 PM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> [...]
> As said before, I think we want an all-or-nothing approach. You
> want to first establish whether the image is a unified one, and
> if so not fall back to reading from disk. Otherwise the claim
> of secure boot above is liable to be wrong.

It seems that the system owner who signs the unified Xen image can
choose to use a config, kernel, initrd, microcode, or xsm from the disk
if they a) reference it in the config file and b) do not embed a named
section in the unified image, in which case the code will
fall back to the read_file() function.

This is essentially the status-quo today, including the shim verification
of the kernel, in that all of the other values are essentially untrusted.

However, as Andrew points out:

On Monday, August 10, 2020 3:31 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
wrote:
> > On Thursday, August 6, 2020 8:14 PM, Andrew Cooper 
> > andrew.cooper3@xxxxxxxxxx wrote:
> > > [...]
> > > 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.
> [...]
> With the proposal here, there are two signed sources; one in Kconfig,
> and one in the embedded xen.cfg file.

I added code that turns off argc/argv parsing if UEFI Secure Boot is
enabled, although it doesn't enforce a config file.  The system owner
could sign a unified image without a config file embedded, in which case
the x86 code path will do the read_file() approach for it and load an
attacker controlled config.

Much like the kexec and live patching options, it is a very caveat lector
sort of thing.  The owner of the machine can build and sign an insecure
hypervisor, kernel, etc configuration, if they want to, although it would
be nice to have some defaults to aim the footguns away from their shoes.
Adding runtime checks out of the early EFI boot path for secure boot status
and turning off some of the obviously risky pieces would be a good next step.

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

"Generally usable with Microsoft's signing key and UEFI ecocsystem",
yeah, we're not really there yet.  There are still open issues in the
wider Linux distributions as well about how to handle things like kernel
command lines and initrd validation, so it's not just Xen.

"Generally usable for users enrolling their own platform key and reviewing
the system configuration details", however, I think we're fairly close to
having the building blocks to put together slightly more secure systems.

Thanks for all of you're detailed comments and thoughts on this patch
discussion!  Hopefully we can converge on something soon.

--
Trammell