linux-kernel - Re: [PATCHv9 04/16] x86/cpu: Defer CR pinning setup until core initcall

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: <98a7a91b-3b46-4407-82a7-5f80443b7e00@intel.com>
Date: Thu, 31 Jul 2025 16:45:15 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: Dave Hansen <dave.hansen@...el.com>, Thomas Gleixner <tglx@...utronix.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, Kees Cook <kees@...nel.org>
CC: Jonathan Corbet <corbet@....net>, Ingo Molnar <mingo@...nel.org>, "Pawan
 Gupta" <pawan.kumar.gupta@...ux.intel.com>, Daniel Sneddon
	<daniel.sneddon@...ux.intel.com>, Kai Huang <kai.huang@...el.com>, "Sandipan
 Das" <sandipan.das@....com>, Breno Leitao <leitao@...ian.org>, Rick Edgecombe
	<rick.p.edgecombe@...el.com>, Alexei Starovoitov <ast@...nel.org>, Hou Tao
	<houtao1@...wei.com>, Juergen Gross <jgross@...e.com>, Vegard Nossum
	<vegard.nossum@...cle.com>, Eric Biggers <ebiggers@...gle.com>, "Jason
 Gunthorpe" <jgg@...pe.ca>, "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, Luis Chamberlain
	<mcgrof@...nel.org>, Yuntao Wang <ytcoode@...il.com>, Rasmus Villemoes
	<linux@...musvillemoes.dk>, Christophe Leroy <christophe.leroy@...roup.eu>,
	Tejun Heo <tj@...nel.org>, Changbin Du <changbin.du@...wei.com>, Huang Shijie
	<shijie@...amperecomputing.com>, Geert Uytterhoeven
	<geert+renesas@...der.be>, Namhyung Kim <namhyung@...nel.org>, "Arnaldo
 Carvalho de Melo" <acme@...hat.com>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-efi@...r.kernel.org>,
	<linux-mm@...ck.org>, "Kirill A. Shutemov" <kas@...nel.org>, "Kirill A.
 Shutemov" <kirill.shutemov@...ux.intel.com>, Andy Lutomirski
	<luto@...nel.org>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
	<bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra
	<peterz@...radead.org>, Ard Biesheuvel <ardb@...nel.org>, "Paul E. McKenney"
	<paulmck@...nel.org>, Josh Poimboeuf <jpoimboe@...nel.org>, Xiongwei Song
	<xiongwei.song@...driver.com>, Xin Li <xin3.li@...el.com>, "Mike Rapoport
 (IBM)" <rppt@...nel.org>, Brijesh Singh <brijesh.singh@....com>, Michael Roth
	<michael.roth@....com>, Tony Luck <tony.luck@...el.com>, Alexey Kardashevskiy
	<aik@....com>, Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	X86-kernel <x86@...nel.org>
Subject: Re: [PATCHv9 04/16] x86/cpu: Defer CR pinning setup until core
 initcall

On 7/9/2025 10:00 AM, Dave Hansen wrote:
> On 7/7/25 01:03, Kirill A. Shutemov wrote:
>> Instead of moving setup_cr_pinning() below efi_enter_virtual_mode() in
>> arch_cpu_finalize_init(), defer it until core initcall.
> 
> What are the side effects of this move? Are there other benefits? What
> are the risks?
> 

Picking this up from Kirill.. Reevaluating this, core_initcall() seems
too late for setup_cr_pinning().

We need to have CR pinning completed, and the associated static key
enabled before AP bring up. start_secondary()->cr4_init() depends on the
cr_pinning static key to initialize CR4 for APs.

To find the optimal location for CR pinning, here are the constraints:

1) The initialization of all the CPU-specific security features such as
SMAP, SMEP, UMIP and LASS must be done.

2) Since EFI needs to toggle CR4.LASS, EFI initialization must be completed.

3) Since APs depend on the BSP for CR initialization, CR pinning should
happen before AP bringup.

4) CR pinning should happen before userspace comes up, since that's what
we are protecting against.

I shortlisted two locations, arch_cpu_finalize_init() and early_initcall().

a) start_kernel()
     arch_cpu_finalize_init()

arch_cpu_finalize_init() seems like the logical fit, since CR pinning
can be considered as the "finalizing" the security sensitive control
registers. Doing it at the conclusion of CPU initialization makes sense.

b) start_kernel()
     rest_init()
       kernel_init()
         kernel_init_freeable()
           do_pre_smp_initcalls()
             early_initcall()

We could push the pinning until early_initcall() since that happens just
before SMP bringup as well the init process being executed. But, I don't
see any benefit to doing that.

Most of the stuff between arch_cpu_finalize_init() and rest_init() seems
to be arch agnostic (except maybe ACPI). Though the likelihood of
anything touching the pinned bits is low, it would be better to have the
bits pinned and complain if someone modifies them.

I am inclined towards arch_cpu_finalize_init() but I don't have a strong
preference. Dave, is there any other aspect I should consider?

> BTW, ideally, you'd get an ack from one of the folks who put the CR
> pinning in the kernel in the first place to make sure this isn't
> breaking the mechanism in any important ways.

Kees, do you have any preference or suggestions?