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]

Date:	Wed, 17 Oct 2012 16:07:36 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Josh Boyer <jwboyer@...il.com>
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 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
is different from what we used to do before: we stripped the modules
as we copied them to /lib/modules (where the RPM build obviously would
have that $RPM_BUILD_ROOT prefix on the module install path).

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.

                      Linus
--
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/