Messages in this thread | | | From | David Howells <> | Subject | Re: Should we automatically generate a module signing key at all? | Date | Tue, 19 May 2015 16:30:17 +0100 |
| |
Andy Lutomirski <luto@amacapital.net> wrote:
> I'll assume that everyone uses a 256-bit hash.
UEFI makes it very likely that SHA256 is in use, at least on x86_64.
> The public key is tiny, and the signature is 512 bytes per module. > (Actually, it's probably more because of PKCS garbage.
There is metadata selecting the particular key to be checked against, so with a 512-byte signature, you get around 500 bytes of metadata and ASN.1 wrappings. We could probably trim that some more by removing PKCS#7 attribute sections.
We do have to allow people to load external modules. Yes, you could argue that you should just disable all your security systems if you want to do that...
> This is a total of ~21kB of non-swappable storage and 2MB of disk space for > all the signatures.
Disk space is a lot cheaper than RAM.
> Ed25519
Is it endorsed by various governmental authorities? It's not entirely clear. And also the aforementioned authorities may mandate minimum key (eg. 2048) and digest sizes (eg. 256) which we need to deal with.
> With the hash-based scheme I outlined, the kernel text needed is > nearly zero.
What matters is kernel text *plus* kernel data.
> What integrity stuff? IIRC dm-verity doesn't use asymmetric crypto at > all. IMA probably does, though.
IMA.
> For firmware validation, there's no good reason it couldn't work exactly > like module signatures.
That's really impractical. It would mean that the kernel would have to be built with a hash, grand-hash, great-grand-hash or whatever that covers every possible firmware blob you might want to load.
If a vendor releases a new firmware blob, this has to be added to the linux-firmware hash list, say, then the hash of that added to the kernel, say, and the kernel rebuilt and reissued before the firmware blob can be used.
With a key-based approach, you just need to get a signature for the new firmware blob. You can even sign it yourself and add your key to your UEFI database.
> For kexec, I think that the main use is for crash dumps
We also want to be able to kexec new kernels on servers to avoid heavy duty hardware reboot cycles. But you can't put the new kernel's hash in the old kernel.
David
| |