Messages in this thread | | | Subject | Re: [RFC][PATCH v2 00/21] x86/pti: Defer CR3 switch to C code | From | Alexandre Chartre <> | Date | Tue, 17 Nov 2020 08:56:23 +0100 |
| |
On 11/16/20 9:17 PM, Borislav Petkov wrote: > On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote: >> This RFC proposes to defer the PTI CR3 switch until we reach C code. >> The benefit is that this simplifies the assembly entry code, and make >> the PTI CR3 switch code easier to understand. This also paves the way >> for further possible projects such an easier integration of Address >> Space Isolation (ASI), or the possibility to execute some selected >> syscall or interrupt handlers without switching to the kernel page-table > > What for? What is this going to be used for in the end? >
In addition to simplify the assembly entry code, this will also simplify the integration of Address Space Isolation (ASI) which will certainly be the primary beneficiary of this change. The main goal of ASI is to provide KVM address space isolation to mitigate guest-to-host speculative attacks like L1TF or MDS. Current proposal of ASI is plugged into the CR3 switch assembly macro which make the code brittle and complex. (see [1])
I am also expected this might help with some other ideas like having syscall (or interrupt handler) which can run without switching the page-table.
>> (and thus avoid the PTI page-table switch overhead). > > Overhead of how much? Why do we care? >
PTI has a measured overhead of roughly 5% for most workloads, but it can be much higher in some cases. The overhead is mostly due to the page-table switch (even with PCID) so if we can run a syscall or an interrupt handler without switching the page-table then we can get this kind of performance back.
> What is the big picture justfication for this diffstat > >> 21 files changed, 874 insertions(+), 314 deletions(-) > > and the diffstat for the ASI enablement? >
The latest ASI RFC (RFC v4) is here [1]. This RFC has ASI plugged directly into the CR3 switch assembly macro. We are working on a new implementation, based on these changes which avoid having to deal with assembly code and makes the implementation more robust.
alex.
[1] ASI RFCv4 - https://lore.kernel.org/lkml/20200504144939.11318-1-alexandre.chartre@oracle.com/
| |