linux-kernel - Re: [PATCH 0/2] Secure Boot lock down

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: <346avsxulbkfs2uyjkq4k4oucia3vaaxcsml23lp2cw2kw2mgu@y3aa6zb7wiry>
Date: Thu, 24 Jul 2025 17:03:30 +0200
From: Nicolas Bouchinet <nicolas.bouchinet@....cyber.gouv.fr>
To: sergeh@...nel.org
Cc: Paul Moore <paul@...l-moore.com>, 
	Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>, Xiu Jianfeng <xiujianfeng@...wei.com>, 
	linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>, 
	James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, 
	Yue Haibing <yuehaibing@...wei.com>, Tanya Agarwal <tanyaagarwal25699@...il.com>, 
	Kees Cook <kees@...nel.org>, linux-efi@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 0/2] Secure Boot lock down

On Thu, Jul 24, 2025 at 02:13:41PM +0000, sergeh@...nel.org wrote:
> On Thu, Jul 24, 2025 at 02:59:39PM +0200, Nicolas Bouchinet wrote:
> > Hi Hamza, thanks for your patch.
> > 
> > Thanks, Paul, for the forward. 
> > 
> > Sorry for the delay, we took a bit of time to do some lore archaeology
> > and discuss it with Xiu. 
> > 
> > As you might know, this has already been through debates in 2017 [1]. At
> > that time, the decision was not to merge this behavior. 
> > 
> > Distros have indeed carried downstream patches reflecting this behavior
> > for a long time and have been affected by vulnerabilities like
> > CVE-2025-1272 [2], which is caused by the magic sprinkled in
> > setup_arch(). 
> > 
> > While your implementation looks cleaner to me. One of the points in
> > previous debates was to have a Lockdown side Kconfig knob to enable or
> > not this behavior. It would gate the registration of the Lockdown LSM to
> > the security_lock_kernel_down() hook. 
> 
> Well, but there is a default-n kconfig.  What do you mean by "Lockdown
> side Kconfig knob"?  I'm sure I'm missing something, but not sure
> what...
> 
Sorry, if I have been unclear, I talk about something like a 
"LOCK_DOWN_IF_SECURE_BOOT" config in `security/lockdown/Kconfig`.
In addition to the "EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT" in
`drivers/firmware/efi/Kconfig`.

- "EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT" would gate the call to the
  `security_lock_kernel_down` hook and thus to any LSM registered to it.

- "LOCK_DOWN_IF_SECURE_BOOT" would gate the Lockdown LSM registration to
  the `security_lock_kernel_down` hook.

Thanks,

Nicolas