Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 19 May 2015 11:46:19 -0700 | Subject | Re: Should we automatically generate a module signing key at all? |
| |
On May 19, 2015 11:38 AM, "David Howells" <dhowells@redhat.com> wrote: > > Andy Lutomirski <luto@amacapital.net> wrote: > > > > 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. > > > > You could trim even more by simply not using PKCS#7. A raw PKCS#1 > > signature would be just fine. (We should really be using PSS, > > though.) > > Trimming the attributes reduces it to about 150 bytes over the signature. > PKCS#7 is handy because it's a standard that has standard ways of specifying > digest and crypto algorithms and key lookups. Plus we need it available to > verify PE-signed kernel images. > > > ...and for users who need to comply with unfortunate standards, > > If you want to get into certain markets, you have to care. > > > The kernel data involved is 32 bytes. > > No, it isn't. It's the entire hash list and whatever metadata it requires. > Dynamically loaded kernel data is *still* kernel data. >
No, in the hash tree variant, it really is 32 bytes. No one ever needs the full list once the build is done.
> > I don't think that the needs of IMA users should affect normal people > > who run 'make' on their kernel tree. > > The sad fact is that 'normal' Linux users use distribution kernels and don't > give two figs about how it does what it does (or use something like Android > and don't even realise Linux exists). I'm not that sure people who build > their own kernels can really said to be 'normal' in this sense. > > > Deterministic builds can't apply to firmware regardless, so users are > > trusting a vendor one way or another. And for Chromebook or > > Atomic-like uses, hashes are fine. > > That may be so, but that doesn't help Fedora, RHEL and suchlike that run on > less restricted hardware. For an embedded platform, a monolithic kernel may > also be fine.
Both Fedora and RHEL seems to be moving toward having fully-supported configurations with immutable root images. Building those images reproducibly would be fantastic. (Of course, if Fedora or RHEL wants to allow support out-of-tree drivers, that's a different story.)
--Andy
| |