linux-kernel - Re: RFC: sign the modules at install time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+5PVA5TRAo7zu--_jd7yAqsSVHH9pdxkPh4v=rtfXTZVub0Zg@mail.gmail.com>
Date:	Wed, 17 Oct 2012 19:20:51 -0400
From:	Josh Boyer <jwboyer@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Miller <davem@...emloft.net>,
	Rusty Russell <rusty@...tcorp.com.au>,
	David Howells <dhowells@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: RFC: sign the modules at install time

On Wed, Oct 17, 2012 at 7:07 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, Oct 17, 2012 at 3:26 PM, Josh Boyer <jwboyer@...il.com> wrote:
>>
>> The downside is that it won't work for distros.  Or at least the distros
>> using RPM's debuginfo subpackage mechanism.
>
> Hmm. It *should* work for them too, because the debuginfo modules stay
> around in the object tree, and never get stripped there. None of this

Debuginfo is run on the installed tree ($RPM_BUILD_ROOT), not the
object tree.  It's how RPM works.  It kind of has to because it should
only create debuginfo files for files that are actually installed by
the RPM.

I know it's no different from how it _used_ to work with stripped
modules, but that's a problem that was solved a while ago.  The existing
build system works for both users and distros in that regard, and that
is my goal for modsigning too.

> Anyway, I seriously think that the kernel build should worry about
> *users*, not about the distro building their binaries. And I do think
> the current mess is unacceptable (following the insane
> "stripped->extra stripping->signed->potentially stripped *again* at
> install time" code was just insane). I may not have reacted as much as
> David to the actual build having slowed down, but having looked at the
> makefiles, there really is no excuse for that mess.

I'm not saying your patch is wrong.  I'm not even saying it isn't
better.  I'm simply saying it doesn't work as-is for distros.

What I'd like to do is come up with a solution that works for both
cases.  E.g. if we take your patch and apply it, but also create a
config option and a 'make modules_sign' target to sign them in the
installed tree and not at 'modules_install' time.  Or something along
those lines.

Distros want to do this too, and have been doing this for a while.  It
might be required for Secure Boot in some distro's eyes, but that is
really a side effect.  Distros _are_ users.  Or if you're not as starry
eyed as I am, they're at least a gateway for a large number of users.
I want those people to get the benefits of signed modules and I'd really
like to do it without the distros having to carry patches or do further
monkeying around after the buildsystem is done.  That's all.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/