From: Dave Hansen <dave.hansen@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>,
"Mehta, Sohil" <sohil.mehta@intel.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Ard Biesheuvel <ardb@kernel.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Xiongwei Song <xiongwei.song@windriver.com>,
"Li, Xin3" <xin3.li@intel.com>,
"Mike Rapoport (IBM)" <rppt@kernel.org>,
Brijesh Singh <brijesh.singh@amd.com>,
Michael Roth <michael.roth@amd.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Alexey Kardashevskiy <aik@amd.com>
Cc: Jonathan Corbet <corbet@lwn.net>, Ingo Molnar <mingo@kernel.org>,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
Daniel Sneddon <daniel.sneddon@linux.intel.com>,
"Huang, Kai" <kai.huang@intel.com>,
Sandipan Das <sandipan.das@amd.com>,
Breno Leitao <leitao@debian.org>,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
Alexei Starovoitov <ast@kernel.org>, Hou Tao <houtao1@huawei.com>,
Juergen Gross <jgross@suse.com>,
Vegard Nossum <vegard.nossum@oracle.com>,
Kees Cook <kees@kernel.org>, Eric Biggers <ebiggers@google.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Yuntao Wang <ytcoode@gmail.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Tejun Heo <tj@kernel.org>, Changbin Du <changbin.du@huawei.com>,
Huang Shijie <shijie@os.amperecomputing.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Namhyung Kim <namhyung@kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>
Subject: Re: [PATCH v5 05/16] x86/cpu: Defer CR pinning setup until after EFI initialization
Date: Tue, 29 Oct 2024 15:52:56 -0700 [thread overview]
Message-ID: <34dd023d-3ed5-4655-88be-14a7a300b91e@intel.com> (raw)
In-Reply-To: <SJ1PR11MB6083B9854320176B6301C530FC4B2@SJ1PR11MB6083.namprd11.prod.outlook.com>
On 10/29/24 15:26, Luck, Tony wrote:
>> /*
>> * This needs to follow the FPU initializtion, since EFI depends on it.
>> + * It also needs to precede the CR pinning setup, because we need to be
>> + * able to temporarily clear the CR4.LASS bit in order to execute the
>> + * set_virtual_address_map call, which resides in lower addresses and
>> + * would trip LASS if enabled.
>> */
>
> Why are the temporary mappings used to patch kernel code in the lower half
> of the virtual address space?
I was just asking myself the same thing. The upper half is always
mapped uniformly. When you create an MM you copy the 256->511th pgd
entries verbatim from the init_mm's pgd.
If you map something the <=255th pgd entry, it isn't (by default)
visible to other mm's. That's why a new mm also tends to get you a new
process.
> But couldn't we map into upper half and do some/all of:
>
> 1) Trust that there aren't stupid bugs that dereference random pointers into the
> temporary mapping?
> 2) Make a "this CPU only" mapping
> 3) Avoid preemption while patching so there is no need for TLB shootdown
> by other CPUs when the temporary mapping is torn down, just flush local TLB.
It's about enforcing R^X semantics. We should limit the time and scope
where mappings have some data both writeable and executable.
If we poke text in the upper half of the address space, any kernel
thread might be exploited to write to what will soon be executable.
If we do it in the lower half in its own mm, you have to compromise the
thread doing the text poking after the mapping is created but before it
is invalidated. With LASS you *ALSO* need to do it in the STAC/CLAC
window which is smaller than the window when the TLB is valid.
*IF* we switched things to do text poking in the upper half of the
address space, we'd probably want to find a completely unused PGD entry.
I'm not sure off the top of my head if we have a good one for that or
if it's worth the trouble.
next prev parent reply other threads:[~2024-10-29 22:53 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 16:07 [PATCH v5 00/16] Enable Linear Address Space Separation support Alexander Shishkin
2024-10-28 16:07 ` [PATCH v5 01/16] x86/cpu: Enumerate the LASS feature bits Alexander Shishkin
2024-10-29 14:55 ` Kirill A. Shutemov
2024-10-29 21:46 ` Sohil Mehta
2024-10-28 16:07 ` [PATCH v5 02/16] x86/asm: Introduce inline memcpy and memset Alexander Shishkin
2024-10-28 16:07 ` [PATCH v5 03/16] x86/alternatives: Disable LASS when patching kernel alternatives Alexander Shishkin
2024-10-28 17:49 ` Dave Hansen
2024-10-29 11:36 ` Peter Zijlstra
2024-10-29 18:48 ` Peter Zijlstra
2024-10-30 7:40 ` Alexander Shishkin
2024-10-28 16:07 ` [PATCH v5 04/16] init/main.c: Move EFI runtime service initialization to x86/cpu Alexander Shishkin
2024-10-29 22:35 ` Sohil Mehta
2024-10-30 7:36 ` Ard Biesheuvel
2024-10-28 16:07 ` [PATCH v5 05/16] x86/cpu: Defer CR pinning setup until after EFI initialization Alexander Shishkin
2024-10-29 22:10 ` Sohil Mehta
2024-10-29 22:26 ` Luck, Tony
2024-10-29 22:52 ` Dave Hansen [this message]
2024-10-29 22:59 ` Luck, Tony
2024-10-29 23:02 ` H. Peter Anvin
2024-10-29 23:03 ` Dave Hansen
2024-10-29 23:05 ` H. Peter Anvin
2024-10-29 23:18 ` Luck, Tony
2024-10-29 23:41 ` H. Peter Anvin
2024-10-30 11:43 ` Kirill A. Shutemov
2024-10-28 16:07 ` [PATCH v5 06/16] efi: Disable LASS around set_virtual_address_map call Alexander Shishkin
2024-10-29 15:00 ` Kirill A. Shutemov
2024-10-28 16:07 ` [PATCH v5 07/16] x86/vsyscall: Reorganize the #PF emulation code Alexander Shishkin
2024-10-28 16:07 ` [PATCH v5 08/16] x86/traps: Consolidate user fixups in exc_general_protection() Alexander Shishkin
2024-10-28 16:07 ` [PATCH v5 09/16] x86/vsyscall: Add vsyscall emulation for #GP Alexander Shishkin
2024-10-28 16:07 ` [PATCH v5 10/16] x86/vsyscall: Disable LASS if vsyscall mode is set to EMULATE Alexander Shishkin
2024-10-28 16:07 ` [PATCH v5 11/16] x86/vsyscall: Document the fact that vsyscall=emulate disables LASS Alexander Shishkin
2024-10-29 23:41 ` Sohil Mehta
2024-10-28 16:08 ` [PATCH v5 12/16] x86/cpu: Set LASS CR4 bit as pinning sensitive Alexander Shishkin
2024-10-28 16:08 ` [PATCH v5 13/16] x86/traps: Communicate a LASS violation in #GP message Alexander Shishkin
2024-10-28 16:08 ` [PATCH v5 14/16] x86/cpu: Make LAM depend on LASS Alexander Shishkin
2024-10-31 0:06 ` Sohil Mehta
2024-10-28 16:08 ` [PATCH v5 15/16] x86/cpu: Enable LASS during CPU initialization Alexander Shishkin
2024-10-28 16:08 ` [PATCH v5 16/16] Revert "x86/lam: Disable ADDRESS_MASKING in most cases" Alexander Shishkin
2024-10-28 20:41 ` Kirill A. Shutemov
2024-10-28 22:00 ` Alexander Shishkin
2024-10-29 17:14 ` [PATCH v5 00/16] Enable Linear Address Space Separation support Matthew Wilcox
2024-10-30 7:16 ` Alexander Shishkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34dd023d-3ed5-4655-88be-14a7a300b91e@intel.com \
--to=dave.hansen@intel.com \
--cc=acme@redhat.com \
--cc=aik@amd.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=ardb@kernel.org \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=changbin.du@huawei.com \
--cc=christophe.leroy@csgroup.eu \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=ebiggers@google.com \
--cc=geert+renesas@glider.be \
--cc=houtao1@huawei.com \
--cc=hpa@zytor.com \
--cc=jgg@ziepe.ca \
--cc=jgross@suse.com \
--cc=jpoimboe@kernel.org \
--cc=kai.huang@intel.com \
--cc=kees@kernel.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=luto@kernel.org \
--cc=mcgrof@kernel.org \
--cc=mhiramat@kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=paulmck@kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=sandipan.das@amd.com \
--cc=shijie@os.amperecomputing.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=tony.luck@intel.com \
--cc=vegard.nossum@oracle.com \
--cc=x86@kernel.org \
--cc=xin3.li@intel.com \
--cc=xiongwei.song@windriver.com \
--cc=ytcoode@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®