On Tue, 2012-09-25 at 16:30 +0100, Alan Cox wrote: > On Tue, 25 Sep 2012 16:09:54 +0100 > David Howells <dhowells@xxxxxxxxxx> wrote: > > > > > The X.509 certificate has a pair of times in it that delineate the valid > > period of the cert, and I'm checking that the system clock is within the > > bounds they define before permitting you to use the cert. I've been setting > > the expiry date to be 100 years in the future - by which time hopefully I > > won't have to worry about it - but occasionally clock skew means a freshly > > built kernel won't boot because the machine trying to boot doesn't think that > > the start time has been reached yet. > > > > Do we actually want to do this, however? Or should we just ignore the times? > > Or just the start time? > > Generate a certificate that is valid from a few minutes before the > wallclock time. It's a certificate policy question not a kernel hackery > one. That's not good enough. I frequently encounter laptops with hardware clocks which are *way* slower than that. I see lots of machines booting up thinking it's 1970, 1900 iirc for some Macs, and more recently 2001. This causes the kernel to refuse to load the certificate: [ 3.116185] Loading module verification certificates [ 3.117414] X.509: Cert e1a74f2317b1f38848278d07926ed16c2675393e is not yet valid [ 3.118639] MODSIGN: Problem loading in-kernel X.509 certificate (-129) ...and then spew error messages every time a module is loaded. For the kernel, it makes *absolutely* no sense to be checking the start date of the certificate. We do not have a usage model where someone says "hey, here's this kernel module but I don't want you to be able to use it until tomorrow so I've post-dated its signature". If we *ever* try to load a signed kernel module when the certificate is "not yet valid", it's because the clock is wrong. It's as simple as that. And even if we *did* want to support that stupid "load this tomorrow" use case, it's broken. You couldn't boot today, then load the offending module tomorrow. You'd have to *reboot* tomorrow, because the kernel refused to load the damn cert into its store at all. For the specific case of module signing, we should probably just disable the date checks completely. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
