Re: Should we automatically generate a module signing key at all?

[David Howells]

Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/