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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 06/08/2020 15:15, Trammell Hudson wrote:
> On Thursday, August 6, 2020 2:04 PM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
>> On 06.08.2020 13:44, Trammell Hudson wrote:
>>
>>> On Thursday, August 6, 2020 9:57 AM, Jan Beulich jbeulich@xxxxxxxx wrote:
>>>> Also, considering kernel and initrd are embedded, is there really a
>>>> strict need for a config file? It would seem to me that you could
>>>> boot the system fine without.
>>> The config file is still necessary for Xen options (console, etc) as
>>> well as the kernel command line.
>> But command line options are optional. Yes, you need a config file if
>> you want to pass any options. But you may be able to get away without
>> command line options, and hence without config file.
> My concern is that if there is no config file embedded in the unified
> image, then the logic for retrieving the untrustworthy file from disk
> kicks in.  However, it is not a change from the status-quo, so I've
> reverted the behavior (as part of also fixing the shim logic).
>
> I also added code to load the ucode section from the unified image
> if it is present, which required touching the arm tree as well to add
> an additional parameter to efi_arch_cfg_file_late().  It also
> appears that in the event of the error path that the ucode will
> never be freed.  Probably not a big deal, unless you're launching
> a failing Xen from the EFI shell over and over.

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.

I can't think of a Xen example offhand, but consider Linux's
"unsafe_fsgsbase" command line option which was inserted for a period of
time which deliberately opened up a privilege escalation vulnerability
for the purpose of testing the FSGSBASE series carefully.

I suppose the closest which Xen has is probably "ats" (but you've lost
all security by using PCI Passthrough anyway...), but there are also
problems with things like "flask=disabled", "hardware_domain", the
various IVRS/DMAR fixup options.

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.

Beyond that, things like LIVEPATCH and KEXEC need compiling out, until
they can be taught to verify signatures.

Beyond that, things like the GDB serial stub probably need a way of
being able to be compiled out, and then being compiled out.  (This is
definitely not an exhaustive list.)

Xen's secureboot requirements also extend to the dom0 kernel, due to the
responsibility-sharing which currently exists.  For a Linux dom0, Xen
must ensure that lockdown mode is forced on (/dev/mem in dom0 still has
a lot of system level power).  At a minimum, this involves extending
lockdown mode to prohibit the use of /{dev/proc}/xen/privcmd, which is
still a trivial privilege escalation hole in PV Linux that noone seems
to want to admit to and fix.


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 know Safeboot has different goals/rules here, but whatever we put
together called "Secure Boot support" will have to be compatible with
Microsoft's model for it to be useful in the general case.

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.

~Andrew