[U-Boot] EFIBootGuard for CIP and SecureBoot

Fri Apr 26 11:21:54 UTC 2019

On 26.04.19 12:21, Grant Likely wrote:
> On 26/04/2019 10:49, Jan Kiszka wrote:
>> On 26.04.19 11:07, Francois Ozog wrote:
> [...]
>>> Here are the guiding principles of our efforts :
>>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>>> processor model update solution
>>> 1) untrusted world cannot update trusted world
>>
>> Conceptually, it can. It's a matter of validating the update by the
>> trusted world before using it. A trusted instance can allow an untrusted
>> one to write version 2, validate that before switching to it, and stick
>> with version 1 if that fails.
>>
>>> 2) what the UEFI implementation does with the capsule is platform
>>> specific
>>> 3) the update capsule payload is opaque
>>>
>>> 1) is a "philosophy" decision. When you have a root of trust down to
>>> the operating system. So in theory everything should be fine. But the
>>> attack surface is such that we can't rule out hacking (and history
>>> prove this is unfortunately a safe assumption). In addition, there may
>>> be liability aspects related to the who does the update: the hardware
>>> platform administrator may not be the legal entity than the operating
>>> system administrator. For instance:
>>> -  on Packet.net could, a customer can flash up to the BL33 untrusted
>>> firmware but that is all.
>>> - A surveillance camera can be operated by city personnel but only law
>>> enforcement agency can see raw video (un-blurred faces and licence
>>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>>> Path but if you allow untrusted world to update the trusted one, city
>>> personnel can overcome the legal restriction.
>>> With 1) this means that even U-Boot code shall not be able/allowed to
>>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>>> Secure EL1/0 software (OPTEE and its applications or something else).
>>> If possible, allowing the operating system administrator to
>>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>>> platform dependent. Hence defeats 0)
>>>
>>> With 2) we do not impose reboot to update. Some platform may impose
>>> reboot or some designers will prefer reboot. We say that there is a
>>> chain of responsibility for updates.
>>> So it is perfectly OK to have a Linux software agent receive an update
>>> by any mean (network, USB, serial...). The agent will pack this (or
>>> those) into a capsule and push it to UEFI implementation.
>>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>>> pleases for the update providing it complies with 1) So the UEFI
>>> implementation can live update up to BL33 firmware.
>>> Should the update be targeted to secure world, then the UEFI
>>> implementation can pass it to S-EL3 for update (platform specific)
>>> which means the update can also be live. It is a designer decision.
>>>
>>> With 3) we have flexibility but sometimes too much flexibility is a
>>> problem. Alexander Graf suggested we can use a FIT object to pass
>>> diverse objects. It is "half" opaque but I really like the idea.
>>> The contents of individual FIT components can be blocks to be placed
>>> at a fix location in a NOR flash or a file, no importance.
>>>
>>> What do everyone think about those design principles ?
>>>
>>
>> UEFI and capsules can be fine for those platform that support it (and
>> it's still a rare feature) and for stuff like boot and peripheral
>> firmware. I don't think it's a wise, future-proof idea to use it for more.
>>
>> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
>> it will evolve towards that (looking at that as both a user as well as
>> an OEM). It's not even present in quite a few of our use cases. In some
>> it will never be - think of safety-critical system: not affordable with
>> such a complex approach like UEFI.
> 
> Can I challenge that view a bit? On the Tianocore side I agree that the
> ecosystem isn't very healthy. That project in particular struggles with
> what to do with board support, having decided early on that board
> support generally doesn't need to be in the main repository.
> 
> However, U-Boot support for the UEFI ABI is improving in leaps and
> bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all
> the Arm SBCs that they support, and enabling UEFI in U-Boot is just a
> config option or two. There is a fair bit of encouragement from within
> the project to enable UEFI by default.

I don't disagree that this aspect is a step forward (though pulling in things 
redundant code via grub & Co is not really progress). But a Unix community would 
have probably designed a technically more elegant solution on a green field than 
the clumsy, legacy-based UEFI interfaces.

> 
> UEFI gets a bad rap at being complicated, but I think the U-Boot work
> has shown that implementing the core UEFI ABI doesn't require much code
> and isn't the complicated mess they everyone fears it to be.

Depends on how much you start to rely on UEFI features.

> 
> I don't see the conflict with safety critical for boot services. I can

Everything is certifiable - with infinite time and money. So you will likely 
reduce the boot process to the very essential of your concrete system, removing 
then unneeded abstractions and stages. Or you will find ways to eliminate that 
from your argumentation, which would definitely include removing runtime services.

> however see the arguement against UEFI runtime services as a poor
> implementation could result in unbounded execution times. There's been
> recent movement on the UEFI spec to make runtime services optional, and
> in U-Boot they are mostly empty stubs.

Of course, it also depends on how much you need from UEFI to boot or to use 
certain services like capsule updates (and which would be gone when you remove 
runtime services).

> 
>> It should not expand further into OS
>> domains. Updating complete filesystems and their content is beyond its
>> duties. We have all the required, tested, matured means for the OS in
>> the OS. For firmware, it can be an option - if that firmware is UEFI
>> compliant, with all needed options.
> 
> Here I agree 100%. Capsule update is a useful ABI for the OS to pass
> firmware update blobs without needing to know specifics about the
> platform, but everything from the kernel on up is out of scope.

OK, that's good.

> 
>> So let's use UEFI and capsules as a one possible building block in the
>> design, but not as the cornerstone. Just like we do mandate that all
>> updates must be served and managed by our IoT cloud ;).
> 
> What do the firmware stacks in your projects look like? What percentage
> are based on U-Boot? Littlekernel? Others?

I don't have absolute numbers. We have a lot of "standard" x86 UEFI systems, 
many U-boot devices (of which, to my knowledge, none is on UEFI yet - no 
surprise, that feature is still too "new"), and quite a few Coreboot designs (so 
far only x86) that just need to load Linux and bypass a lot therefore. There 
will likely be more exotic things but they will likely also do not deserve 
attention.

> 
> UEFI has the advantage that it has a defined ABI, and only a small
> amount of it needs to be implemented to execute UEFI OS loaders (ie. the
> Linux UEFI stub). For the reference platform, I think it makes sense to
> make the design decision that firmware provides UEFI, and the update
> infrastructure is based on that. However, if UEFI doesn't work for a
> particular stack/project then it can be swapped out. There will need to
> be work done on the boot sequence, but all the rest of the OS stack is
> still relevant.

Yes, I would design it in a way that a perfect UEFI implementation can take a 
lot of boot-related tasks like safe boot configuration switching, watchdog 
management, firmware and peripheral updating (possibly in lock-step with the OS) 
etc. But I would always ensure that incomplete or immature UEFI implementations 
will not complicate partial or complete replacements. Because the latter will 
remain the default for quite a while, if not longer, I'm sure. UEFI should not 
become the systemd of unattended device updates (or worse, due to closed 
implementations).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux