Well, I don't, it's pure overhead.  Turning various options off has also revealed build regressions; why the bias towards turning them all on, other than habit?

How about we make signed kernel modules the default, and change the "do you want signed kernel modules" question into "do you want insecure unsigned kernel modules"?

Reversing the polarity of the config variable would make allmodconig and allyesconfig then default to "yes, I want unsigned kernel modules". Hmm?

So we trust the integrity of the entire kernel source tree to SHA1, but we need RSA for the binary result?  Really guys?

I seriously considered the inverse option, but it's a dumb workaround.  If people really want max coverage, they presumably want this on.  If they want some compromise (ie. good coverage but more speed like linux-next), let's specify that exactly.

Dave, distributions want to create signed modules after build.  Static signatures don't get what they want.  You're closer than me to RHEL engineers, surely...

Something like SHA256 or SHA512 fed using an initial key would have been real compromise.  That we can really optimize, even make it faster than that unoptimized MD4 gunky thing we had there to begin with.  You could have provided the functionality, with the potential to make the build faster rather than slower.

I'm sending out a search party, I'll let you know if they find your spine. :-)

Huh?

We could use a hash function on the .ko files, and record them all in a table in the kernel, and refuse to load a module which doesn't match one.

Now, what were you talking about?

(Gah, this is the worst IRC client ever...)

It's better than trying to discuss something I brought up here, on your blog.  That's for sure.

Anyways what really eats me is that I spent the last month or so getting the build down close to 5 minutes flat for allmodconfig.  I was able to get rid of about 45 seconds of build time with that work.  You've just undone that in one fell swoop and I seriously feel like I've wasted my time.

There is no reason turning everything on just to validate that configuration's build should be expensive.

Are you sure that turning everything on is the best way to validate?  Or are people doing what Linus suggested and creating inverse options where you get more coverage with it off.

Also, can you explain your solution which meets RH et al's needs which builds faster?

Rusty, you were the one willing to put even netfilter in userspace.  Why can't the module signature validation go there too? :-)

I've been wondering the same thing.  I believe the answer is that recent vulnerabilities have lead us to abandon the idea that we can trust anything in userspace, and retreat to the kernel.

The concept that the kernel is more secure because we didn't include lots of crap seems to be a heretical thought.

I've been pretty unpopular as I rejected various even-more-crazy approaches; I like your "spineless" criticism as it balances those out -- now I'm unpopular with everyone! :)

I understand the constraints you operate under, believe me :-)

But really, the anti-userland argument doesn't hold much water when the very first thing that happens on bootup is we spawn udev to create something as fundamental as device nodes.

And I don't care if the userland "thing" is in the kernel tree and uses klibc.  All it has to do is patch in an ELF section or something like that with the RSA signature at module install time, and validate it when invoked as /sbin/kmodcheck or whatever you want to call it.

But if the kernel needs to verify that kmodcheck binary, do we gain?  Why not skip the middleman and verify the module?

Does the kernel check whatever binary is randomly invoked on udev events?

I guess I have to resign to accept things as they are, ho hum :-/

AFAICT IMA is trying to do exactly that, with signatures in xattrs.

But I still think allfastconfig would make my life easier :)

+David Miller: what the fuck would be the point of user-land validation, when the whole point of signed kernel modules is "we don't trust somebody who may have gotten root to not insert a malicious kernel module"?

And what's your blathering about trusting the kernel source tree to SHA1 but not binaries? SHA1 is a data integrity thing. It's not a "secure signature". We do have gpg signatures on tags on the source tree too, but those aren't sha1, those are the very RSA that you are ranting against.

Your arguments make no sense.

Wouldn't +Josh Boyer 's proposal in your last post be a decent comprimise. To move the module signing to 'make modules_sign' run before 'make modules_install'?

+Niklas Bolander: I think signing at install time might well work fine too. I haven't seen the patch or the implications, though.

+Niklas Bolander +Linus Torvalds we're carrying it in Fedora.  Basically, it reuses the existing signing scripts from David Howells but works on the installed module tree (e.g. after you call make modules_install).  It's a fairly small patch in and of itself, but it would be the only kbuild target I know of that modifies modules in the installed location.

This needs cleanup to avoid a revert and perhaps allow for both build time and post-install time options, but you can find the quick and dirty version here:

http://jwboyer.fedorapeople.org/pub/modsign-rawhide.patch

+Josh Boyer: forgot to cc you on the email with a simpler patch which just moves things to "make modules_install" and removes a lot of silly crud wrt stripping games etc.

http://permalink.gmane.org/gmane.linux.kernel/1377265

Comments?

+Linus Torvalds It's certainly simpler (I'll reply on-list), but for distros that do debuginfo it won't work.  I wrote this a while ago to explain why:

http://jwboyer.livejournal.com/44787.html

Probably start with the 4th paragraph.  It was written with Fedora planet in mind as the target audience.