linux-kernel - Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures verification

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: <e4e838d03b3619df5523d429e0cd8160a8aef9f8.camel@HansenPartnership.com>
Date: Thu, 05 Jun 2025 08:22:09 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>, Eric Snowberg
	 <eric.snowberg@...cle.com>
Cc: "linux-security-module@...r.kernel.org"
 <linux-security-module@...r.kernel.org>, "linux-integrity@...r.kernel.org"
 <linux-integrity@...r.kernel.org>, "linux-modules@...r.kernel.org"
 <linux-modules@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org"
 <linux-doc@...r.kernel.org>, "keyrings@...r.kernel.org"
 <keyrings@...r.kernel.org>, David Howells <dhowells@...hat.com>, David
 Woodhouse <dwmw2@...radead.org>, Jonathan Corbet <corbet@....net>, Luis
 Chamberlain <mcgrof@...nel.org>,  Petr Pavlu <petr.pavlu@...e.com>, Sami
 Tolvanen <samitolvanen@...gle.com>, Daniel Gomez <da.gomez@...sung.com>,
 Mimi Zohar <zohar@...ux.ibm.com>, Roberto Sassu <roberto.sassu@...wei.com>,
 Dmitry Kasatkin <dmitry.kasatkin@...il.com>,  Paul Moore
 <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, "Serge E. Hallyn"
 <serge@...lyn.com>,  Peter Jones <pjones@...hat.com>, Robert Holmes
 <robeholmes@...il.com>, Jeremy Cline <jcline@...hat.com>,  Coiby Xu
 <coxu@...hat.com>, Gerd Hoffmann <kraxel@...hat.com>
Subject: Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for
 signatures verification

On Thu, 2025-06-05 at 09:54 +0200, Vitaly Kuznetsov wrote:
> One additional consideration is the fact that we already trust 'db'
> for dm-verity (since 6fce1f40e951) and kexec (since 278311e417be) and
> especially the later gives someone who is able to control 'db' access
> to CPL0; a 'db'-signed module (IMO) wouldn't change much.

Well, the kexec case is because kexec has to verify the new kernel as
shim would and shim would use the UEFI keys.  The dm-verity one was
added for a cloud use case by pressuring the maintainers in spite of
the objection to using the platform keyring (it went to dm-devel only
so not many integrity people saw it):

https://lore.kernel.org/all/20240617220037.594792-1-luca.boccassi@gmail.com/

The point here is I do think the cloud use case is legitimate, but it
can't be supported simply by ignoring the bare metal security domain
separation concerns of the integrity community.  The argument that
distros have done it so it must be safe isn't really a winning one
(especially as there's no clear explanation of why they did it).  So
either you need a better argument or we need a way to support both sets
of communities ... which is why I was wondering about a runtime
differentiator.
'
Regards,

James