Fit images and EFI_LOAD_FILE2_PROTOCOL

[François Ozog]

On Tue, 6 Oct 2020 at 10:06, Ard Biesheuvel <ardb at kernel.org> wrote:

>
>
> On Tue, 6 Oct 2020 at 10:00, François Ozog <francois.ozog at linaro.org>
> wrote:
>
>>
>>
>> Le mar. 6 oct. 2020 à 09:21, Ard Biesheuvel <ardb at kernel.org> a écrit :
>>
>>> On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt <xypron.glpk at gmx.de>
>>> wrote:
>>> >
>>> > Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely <
>>> grant.likely at arm.com>:
>>> > >
>>> > >
>>> > >On 03/10/2020 09:51, Heinrich Schuchardt wrote:
>>> > >> Hello Ilias, hello Christian,
>>> > >>
>>> > >> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
>>> > >initramfs
>>> > >> loading") Ilias provided the possibility to specify a device path
>>> > >> (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
>>> > >> served via the EFI_FILE_LOAD2_PROTOCOL.
>>> > >>
>>> > >> Ard extended the Linux EFI stub to allow loading the initial RAM
>>> disk
>>> > >> via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
>>> > >>
>>> > >> With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
>>> > >> IH_OS_EFI") Cristian enabled signed FIT images that contain a device
>>> > >> tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
>>> > >>
>>> > >> In the DTE calls we have discussed that it is unfortunate that we do
>>> > >not
>>> > >> have a method to validate initial RAM images in the UEFI context.
>>> > >>
>>> > >> To me it would look like a good path forward to combine the two
>>> > >ideas:
>>> > >>
>>> > >> * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
>>> > >> * Pass location and size to the UEFI subsystem and serve them via
>>> > >>    the EFI_FILE_LOAD2_PROTOCOL.
>>> > >>
>>> > >> We could also extend the bootefi command to be callable as
>>> > >>
>>> > >>     bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
>>> > >>
>>> > >> like the booti command to serve an initial RAM disk.
>>> > >>
>>> > >> What are your thoughts?
>>> > >
>>> > >Hi Heinrich,
>>> > >
>>> > >I've got concerns about this approach. Even though it uses the UEFI
>>> > >infrastructure, images deployed in this way are U-Boot specific and
>>> > >won't ever be applicable on EDK2 or other UEFI implementations.
>>> > >
>>> > >However there is another way to approach it which I think Francois
>>> > >touched on. If instead a UEFI stub was added to the FIT image, in the
>>> > >same way that the kernel has a UEFI stub, then the logic of decoding
>>> > >the
>>> > >FIT and choosing the correct DTB & initrd can be part of the image and
>>> > >it becomes applicable to any UEFI implementation. It would also
>>> address
>>> > >
>>> > >Ard's concern of loading the FIT into memory, and then copying due to
>>> > >the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
>>> > >in
>>> > >RAM, that is is reserved correctly, and just pass the correct
>>> addresses
>>> > >
>>> > >to the kernel as part of the normal boot flow.
>>> > >
>>> > >Signing would also be taken care of because the whole FIT can be
>>> > >signed,
>>> > >and that signature would be checked when it gets loaded.
>>> > >
>>> > >Thoughts?
>>> > >
>>> >
>>> > The gain of a fit image in U-Boot used for calling the Linux kernel
>>> via the EFI stub vs calling the legacy entry point comes down to providing
>>> the EFI_RNG_PROTOCOL to be used for KASLR.
>>> >
>>> > For initrd a stub UEFI binary will work. But if you want to provide a
>>> kernel specific  dtb with the same stub binary it will require a new
>>> service for device-tree fixups.
>>> >
>>> > Both approaches are on Francois' DTE slidedeck.
>>> >
>>> > When thinking of security what really is unclear to me is how we can
>>> safely provide the decryption key for the root partition. Without such a
>>> means secure boot stops being secure once Linux starts the init process. I
>>> would assume that only the secure world can provide the key.
>>> >
>>>
>>> Secure boot only deals with authentication, which does not require any
>>> secret keys.
>>>
>>> Encrypted file systems are a completely separate matter. Typically,
>>> this is based on TPM-based local attestation, where the decryption key
>>> has been sealed into the TPM, and is only unsealed when all the boot
>>> components check out (based on their 'measurements' [aka hashes] that
>>> are cumulatively recorded in TPM hardware registers called PCRs)
>>>
>>> In general, keeping secrets on a device is much more difficult than
>>> authenticating executable images, and typically involves some user
>>> provided secret, or h/w support. UEFI secure boot only reasons about
>>> authentication.
>>
>>
>> If SecureBoot is involving Microsoft certificate, a US governmental
>> agency could get its code signed and insert itself in a stealth mode (efi
>> apps or drivers -> rootkit?)
>>
>> If the set of keys must include this certificate  , then to achieve
>> SecureBoot you actually need the TPM to control what signed code you
>> accept.
>>
>>
> I am sorry, but this makes no sense at all. Either you trust the MS
> certificate or you don't -
>
I trust the certificate technology  but I may not trust the signature
process at Microsoft: as a consumer I am fine with it, if I were a French
nuclear plant security officer, I wouldn't trust the MS certification
process (because NSA can get Microsoft to sign a piece of code I don't
want).
So trustworthiness or trustworthiness target levels should be defined (an
effort is below and was presented at DTE call)

> if you don't, then you cannot rely on the TPM either, as you are relying
> on the boot chain not to lie about the measurements it sends to the TPM.
> IOW, you can trick the TPM into releasing its secrets by sending the
> 'correct' values that it expects, rather than measurements that were taken
> from the actual boot stages.
>
Indeed. And I think there are countermeasures.
In the same spirit, there are hardware attacks: Riscure proved SecureBoot
can be defeated by injecting 12V on a USB port of a platform:
the pseudo code "if <signature_verified> then <continue_secure_boot> else
<stop_boot_with_alert>"
went on <continue_secure_boot> while signature was bad.


>From the above, and based on Arm defined certification levels, I
postulate that there are three classes of "trustworthiness target levels":
PSA level 1: limited security requirements, self certification
PSA level 2: software attacks (local or remote) resilience, lab certified
PSA level 3: hardware attacks resilience

In this context, it may be defined that:
- a PSA level 2 with basic trustworthiness target level is OK with trusting
the Msft process of certification (basically that is all datacenter, home
computing world)
- a PSA level 3 with high end trustworthiness target level is not OK with
Msft certificate, will require TPM with mitigation of evasion techniques
you mention, provide counter measures (hardware or software) to ensure
guaranteed behavior in key decisions such as "if <signature_verified>",
have non repudiable auditability of events, and a continuous assessment of
measured boot in RAM (this was proposed by OpenFog group - probably by Arm
BTW - while not digging in how this could actually be done).

At the end of the day, trustworthiness target level is about matching the
use case with costs and complexity of management.

There will be thus many trustworthiness target levels. we should define
them and their implications on technologies, processes (OTA...) and
software design patterns (mitigation of hardware attacks when hardware
mitigation is not available). And it may be possible that the high end
trustworthiness levels will never be open source. In any case we shall
define them and state what can be expected from the technologies we build
so that product vendors can characterize the trustworthiness level of their
products.

>
>
> If the certificate can be omitted I would either sign the shim or add the
>> sha256 of trustable ones.
>>
>> The unsealing if keys for rootfs decryption is yet another capability
>> that is offered by TPM to protect against different nature of attacks
>> (conuterfeit products, confidentiality...)
>>
>>>
>>> --
>> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
>> T: +33.67221.6485
>> francois.ozog at linaro.org | Skype: ffozog
>>
>>

-- 
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog