lkml.org 
[lkml]   [2015]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Should we automatically generate a module signing key at all?
Date
Andy Lutomirski <luto@amacapital.net> wrote:

> Suppose you have a depth-k tree (i.e. up to 2^k modules). We'll
> compute a 32-byte value Tree(d, i) for each d from 0 to k and each i
> from 0 to 2^d-1. First you assign each module an index starting at
> zero (with the maximum index less than 2^k). Then you hash each
> module.

Now you've got a different problem. Unless you want to load the entire tree
in one go (in which case you're back to the kernel space issue), the kernel
now has to be able to pull it piecemeal from storage and the initramfs builder
either has to pull in the entire tree or select a subset. Further, if the
initfamfs only contains a subtree, then the kernel has to be able to switch to
the full tree as some point.

> > And that doesn't include the issue of hashing the firmware blobs you might
> > need.
>
> As before, that's true. To verify firmware, either you need to hash
> it, use a termporary signing key, or use a long-term signing key.
> Choose your poison. I still prefer a hash over a temporary signing
> key.

From a distribution point of view, a hash list of all known firmware is icky
as all the kernels maintained by the distribution would have to be updated
each time a new firmware blob needs listing. Further, all past known firmware
would have to be kept in the list and could never be discarded lest you
prevent someone's machine from booting.

David


\
 
 \ /
  Last update: 2015-05-21 18:41    [W:0.194 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site