[This bounced from the list for some reason, so I'm trying again.] Hi Michal,
That's a really interesting proposal - thank you. I'm still thinking about it and experimenting with it in SLOF. Some thoughts: > It has been pointed out in the plumbers session that the ELF note will > cause problems when user wants to add additional signature. > > The normal appended signature has only one size information - in the > footer at the end of the binary, and that is not part of the signed > data. So if you want to add additional signature it if possible to > expand the room for the signature data. The appended signature metadata doesn't contain information about the size of the signed data. It contains the size of the PKCS#7/CMS signature block - because that can change in size based on the hash function and the identity of the signing certificate. Normally this doesn't matter: you can get a size of the whole file from the filesystem and then because you know the size of the appended signature data, you can work out the size of the signed data. > In contrast the ELF note size is present in the ELF header which is > also signed. This does not allow adjusting the size of the signature > data once the binary is signed. Correct. We could potentially allocate lots of space, but you are correct that the size of the ELF note is fixed by the signature. > A simpler scheme would be for grub-install to parse the signature > footer, split-off the signature, write the ELF binary at the start of > the PReP partition, and the signature at the end. Then the grub > signature can use exactly same format as the kernel and modules. I got part way through implementing this today in SLOF and realised that it's not immediately clear what the size of the signed data is for verifying the appended signature - that is, how much of the PReP partition should I be hashing? As I said, the appended signature metadata doesn't encode this particular size value. One thing that we might be able to do is to base the size of the verified data on a size calculated from the ELF header: basically figure out the maximum file offset + size for all the program headers, capped at (partition size - appended signature size), and hash that many bytes. If I understand correctly, and assuming grub-mkimage constructs valid ELF files, this should be correct. I'll give this a go in SLOF tomorrow, and I'll also need to confer with the team that develops the proprietary firmware used by PowerVM. > The disadvantage is that for signed grub dd is no longer an alternative > to grub-install. > > There was also concern about distinguishing signed and un-signed grub. > That is that writing an un-signed grub might lease a stale signature > leading to an error. > > However, secure boot is something that should be enabled or disabled in > firmware settings, and not triggered by the PPeP partition containing a > signature. > > When secure boot is enabled checking the grub signature is required and > un-signed grub is invalid. When secure boot is disabled the signature > is irrelevant and stale signature should not cause any error. What I'm concerned about here - and it's possible I explained it poorly at Plumbers - is how a systems administrator would distinguish between having accidentally installed an unsigned grub, and having installed a grub with a broken or untrusted signature. Having said that, ... > grub-install can also remove the signature magic when installing > un-signed grub for consistency. Users using dd to install un-signed > grub might still have an old signature at the end of the partition. if we make grub-install do the right thing, I think that sufficiently mitigates my concern. Thanks again, and I'll let you know how I get on shortly. Kind regards, Daniel _______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
