On Thu, Jan 09, 2020 at 10:03:33PM +0200, Ilias Apalodimas wrote:
On Thu, Jan 09, 2020 at 08:09:27PM +0100, Heinrich Schuchardt wrote:
On 1/9/20 9:02 AM, Ilias Apalodimas wrote:
On Thu, Jan 09, 2020 at 01:08:35AM +0100, Heinrich Schuchardt wrote:
On 12/18/19 1:44 AM, AKASHI Takahiro wrote:
One of major missing features in current UEFI implementation is "secure boot." The ultimate goal of my attempt is to implement image authentication based on signature and provide UEFI secure boot support which would be fully compliant with UEFI specification, section 32[1]. (The code was originally developed by Patrick Wildt.)
Please note, however, this patch doesn't work on its own; there are a couple of functional dependencies[2] and [3], that I have submitted before. For complete workable patch set, see my repository[4], which also contains experimental timestamp-based revocation suuport.
My "non-volatile" support[5], which is under discussion, is not mandatory and so not included here, but this inevitably implies that, for example, signature database variables, like db and dbx, won't be persistent unless you explicitly run "env save" command and that UEFI variables are not separated from U-Boot environment. Anyhow, Linaro is also working on implementing real "secure storage" solution based on TF-A and OP-TEE.
Device trees can be used for denial of service or to destroy hardware.
How will you address the validation of device trees?
Although this is really simple to solve, factoring in the different vendor needs makes it quite complex. There's a couple of options we can consider and not all of them are sane.
- U-Boot embeds the DTB. This is straightforward. On Arm devices TF-A
verifies U-boot so you natively end up with a verified DTB. If U-Boot does not include the proper DTB (as is the case for several devices), one can always complite the correct DTB and compile with EXT_DTB. 2. Use https://github.com/jiazhang0/SELoader which verifies non-PE files 3. Add some custom code and use UEFI keyring to verify non PE files. This is a bad idea though since you'll 'polute' the UEFI keyring. 4. FIT for DTB (??)
In any case UEFI job is to verify PE/COFF executables and that's what this patch provides. DTB verification is beyond UEFI secure boot patches imho.
Regards /Ilias
The UEFI specification does not mention device trees at all. EDK2 is based on ACPI tables.
On one of the platforms i kknow of (socionext synquacer), it also provides DTB as part of the firmware, which is identical to proposeal (1) I mentioned.
We already have verified boot via signed UEFI FIT images which can contain an UEFI image and a device tree. So for verified boot of Linux you would simply package shim and the device tree into a FIT image. Shim would verify GRUB and GRUB would verify the kernel and the ramdisk. In this scenario we don't need the current patch series at all and it integrates well with distributions like Debian which provide shim for arm64, cf. https://packages.debian.org/de/bullseye/shim-signed .
Of course everything is verified, but that's not UEFI secure boot. It's similar but the verification does not go through DB/DBX and there are no secure variables, so the current patchset has value.
I believe that db/dbx schemes give us, distributors as well as users, more flexible manner of managing secure boot process.
If we implement secure boot according the UEFI specification, one option would be to package the device tree as a UEFI driver image and let the stub install it as a configuration table. The unload callback could be used to remove the device tree.
Sure but this is not in scope for the current patchset is it?
Exactly.
Similarly you can just include the DTB in U-Boot and naturally have it verified.
I am not arguing that DTB verification is needed. We absolutely agree on that. All i am saying is that the extra functionality can be added in the future, since we already have a valid way of providing it with the current patchset.
BTW, Ilias, where should such a discussion about dtb verification be held, Boot-arch ML, Linaro Connect, ELC or whatever else conference? Otherwise just leave the decision in distributors' hands?
Thanks, -Takahiro Akashi
Regards /Ilias
Best regards
Heinrich