[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5cab2a0e-1034-8748-fcbe-a17cf4fa2cd4@intel.com>
Date: Thu, 11 Jul 2019 15:38:46 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Alexandre Chartre <alexandre.chartre@...cle.com>,
pbonzini@...hat.com, rkrcmar@...hat.com, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, hpa@...or.com,
dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
kvm@...r.kernel.org, x86@...nel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Cc: konrad.wilk@...cle.com, jan.setjeeilers@...cle.com,
liran.alon@...cle.com, jwadams@...gle.com, graf@...zon.de,
rppt@...ux.vnet.ibm.com
Subject: Re: [RFC v2 00/27] Kernel Address Space Isolation
On 7/11/19 7:25 AM, Alexandre Chartre wrote:
> - Kernel code mapped to the ASI page-table has been reduced to:
> . the entire kernel (I still need to test with only the kernel text)
> . the cpu entry area (because we need the GDT to be mapped)
> . the cpu ASI session (for managing ASI)
> . the current stack
>
> - Optionally, an ASI can request the following kernel mapping to be added:
> . the stack canary
> . the cpu offsets (this_cpu_off)
> . the current task
> . RCU data (rcu_data)
> . CPU HW events (cpu_hw_events).
I don't see the per-cpu areas in here. But, the ASI macros in
entry_64.S (and asi_start_abort()) use per-cpu data.
Also, this stuff seems to do naughty stuff (calling C code, touching
per-cpu data) before the PTI CR3 writes have been done. But, I don't
see anything excluding PTI and this code from coexisting.
Powered by blists - more mailing lists