linux-kernel - Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

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: <bf3f2f1c-1852-449f-993f-71848d190db6@archlinux.org>
Date: Sat, 3 May 2025 01:43:06 +0200
From: kpcyrd <kpcyrd@...hlinux.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>,
 Thomas Weißschuh <linux@...ssschuh.net>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
 Nathan Chancellor <nathan@...nel.org>, Arnd Bergmann <arnd@...db.de>,
 Luis Chamberlain <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>,
 Sami Tolvanen <samitolvanen@...gle.com>, Daniel Gomez
 <da.gomez@...sung.com>, Paul Moore <paul@...l-moore.com>,
 James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
 Jonathan Corbet <corbet@....net>, Madhavan Srinivasan <maddy@...ux.ibm.com>,
 Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Naveen N Rao <naveen@...nel.org>, Mimi Zohar <zohar@...ux.ibm.com>,
 Roberto Sassu <roberto.sassu@...wei.com>,
 Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
 Eric Snowberg <eric.snowberg@...cle.com>,
 Nicolas Schier <nicolas.schier@...ux.dev>,
 Fabian Grünbichler <f.gruenbichler@...xmox.com>,
 Arnout Engelen <arnout@...t.net>, Mattia Rizzolo <mattia@...reri.org>,
 Christian Heusel <christian@...sel.eu>, Câju Mihai-Drosi
 <mcaju95@...il.com>, linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
 linux-modules@...r.kernel.org, linux-security-module@...r.kernel.org,
 linux-doc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
 linux-integrity@...r.kernel.org
Subject: Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

On 5/2/25 3:30 PM, James Bottomley wrote:
> Under a your interpretation of the above, any signed binary isn't
> "reproducible" even if the underlying build was, which means any secure
> boot kernel would never be reproducible because it also has to be a
> signed binary.  The solution is simple: can you strip the signature and
> reproduce the build?  If yes, then the build is reproducible and even
> fits with the "any party can recreate ..." above.   This is the
> interpretation pretty much everyone else has been using.  It's why
> people like Intel with source only availability and Intel build only
> signing tout reproduceability: they only issue signed confidential VM
> firmware, but you can technically reproduce the build of the firmware
> minus the signature but you can never sign it.

The secure-boot signature is easier to deal with, I also think there'd 
be one package that contains just the unsigned kernel+modules (with the 
modules being pinned by a cryptographic hashset), and a second one that 
takes the kernel secure-boot signature as a source-code input, that is 
calculated after the first package was successfully built.

Arch Linux has also considered patching the module-signing-script into 
some kind of oracle that doesn't use any private key and instead selects 
the right pre-computed signature for the given content, but:

- that would be terribly annoying to maintain/operate
- any reproducible builds regression would make the build fail, because 
the kernel wouldn't be bootable

> You just strip the signatures before verifying reproducibility.
> 
[...]
> 
> If you take off the appended signature off the module, you can verify
> reproduceability.
> 
[...]
> 
> So you think stripping signatures is failure prone?  If that were the
> case then so would be verifying signatures upon which our whole secure
> boot and signed module loading is based.
> 
[...]
> 
> Or you simply ship tools to remove the signature;
> 
> sbattach --remove <signed efi variable>
> 
> already does this for you ...

It reads like you assume somebody sits down and explicitly looks at the 
linux package manually, but the reproducible builds tooling considers 
the package content to be fully opaque and doesn't have any 
special-casing of any package:

https://github.com/archlinux/archlinux-repro
https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/debrebuild.pl?ref_type=heads

I'd rather not deal with the consequences of weakening the comparison 
and possibly introducing exploitable loop-holes in any of the layers we 
wouldn't be able to bit-for-bit compare anymore (like e.g. tar).

It would also break the concept of `f(source) -> binary`, "you can 
deterministically derive the binary packages from the documented build 
inputs", and instead you'd always need to fuzzy-match against what 
somebody else built.

cheers,
kpcyrd