On Tue, Nov 17 2020 at 09:19, Alexandre Chartre wrote:
> On 11/16/20 9:24 PM, Borislav Petkov wrote:
>> On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:
>> So PTI was added exactly to *not* have kernel memory mapped in the user
>> page table. You're partially reversing that...
>
On 11/18/20 12:29 PM, Borislav Petkov wrote:
On Wed, Nov 18, 2020 at 08:41:42AM +0100, Alexandre Chartre wrote:
Well, it looks like I wrongfully assume that KPTI was a well known performance
overhead since it was introduced (because it adds extra page-table switches),
but you are right I
On 11/18/20 2:22 PM, David Laight wrote:
From: Alexandre Chartre
Sent: 18 November 2020 10:30
...
Correct, this RFC is not changing the overhead. However, it is a step forward
for being able to execute some selected syscalls or interrupt handlers without
switching to the kernel page-table.
From: Alexandre Chartre
> Sent: 18 November 2020 10:30
...
> Correct, this RFC is not changing the overhead. However, it is a step forward
> for being able to execute some selected syscalls or interrupt handlers without
> switching to the kernel page-table. The next step would be to identify and
On Wed, Nov 18, 2020 at 08:41:42AM +0100, Alexandre Chartre wrote:
> Well, it looks like I wrongfully assume that KPTI was a well known performance
> overhead since it was introduced (because it adds extra page-table switches),
> but you are right I should be presenting my own numbers.
Here's one
On 11/18/20 10:30 AM, David Laight wrote:
From: Alexandre Chartre
Sent: 18 November 2020 07:42
On 11/17/20 10:26 PM, Borislav Petkov wrote:
On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote:
Some benchmarks are available, in particular from phoronix:
What I was expecting
From: Alexandre Chartre
> Sent: 18 November 2020 07:42
>
>
> On 11/17/20 10:26 PM, Borislav Petkov wrote:
> > On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote:
> >> Some benchmarks are available, in particular from phoronix:
> >
> > What I was expecting was benchmarks *you* have
On 11/17/20 10:26 PM, Borislav Petkov wrote:
On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote:
Some benchmarks are available, in particular from phoronix:
What I was expecting was benchmarks *you* have run which show that
perf penalty, not something one can find quickly on
On 11/17/20 10:23 PM, Borislav Petkov wrote:
On Tue, Nov 17, 2020 at 08:02:51PM +0100, Alexandre Chartre wrote:
No. This prevents the guest VM from gathering data from the host
kernel on the same cpu-thread. But there's no mitigation for a guest
VM running on a cpu-thread attacking another
On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote:
> Some benchmarks are available, in particular from phoronix:
What I was expecting was benchmarks *you* have run which show that
perf penalty, not something one can find quickly on the internet and
something one cannot always
On Tue, Nov 17, 2020 at 08:02:51PM +0100, Alexandre Chartre wrote:
> No. This prevents the guest VM from gathering data from the host
> kernel on the same cpu-thread. But there's no mitigation for a guest
> VM running on a cpu-thread attacking another cpu-thread (which can be
> running another
On 11/17/20 7:28 PM, Borislav Petkov wrote:
On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote:
Yes. L1TF/MDS allow some inter cpu-thread attacks which are not mitigated at
the moment. In particular, this allows a guest VM to attack another guest VM
or the host kernel running
On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote:
> Yes. L1TF/MDS allow some inter cpu-thread attacks which are not mitigated at
> the moment. In particular, this allows a guest VM to attack another guest VM
> or the host kernel running on a sibling cpu-thread. Core Scheduling
On 11/17/20 6:07 PM, Borislav Petkov wrote:
On Tue, Nov 17, 2020 at 09:19:01AM +0100, Alexandre Chartre wrote:
We are not reversing PTI, we are extending it.
You're reversing it in the sense that you're mapping more kernel memory
into the user page table than what is mapped now.
PTI
On 11/17/20 5:55 PM, Borislav Petkov wrote:
On Tue, Nov 17, 2020 at 08:56:23AM +0100, Alexandre Chartre wrote:
The main goal of ASI is to provide KVM address space isolation to
mitigate guest-to-host speculative attacks like L1TF or MDS.
Because the current L1TF and MDS mitigations are
On Tue, Nov 17, 2020 at 09:19:01AM +0100, Alexandre Chartre wrote:
> We are not reversing PTI, we are extending it.
You're reversing it in the sense that you're mapping more kernel memory
into the user page table than what is mapped now.
> PTI removes all kernel mapping from the user page-table.
On Tue, Nov 17, 2020 at 08:56:23AM +0100, Alexandre Chartre wrote:
> The main goal of ASI is to provide KVM address space isolation to
> mitigate guest-to-host speculative attacks like L1TF or MDS.
Because the current L1TF and MDS mitigations are lacking or why?
> Current proposal of ASI is
On 11/16/20 9:24 PM, Borislav Petkov wrote:
On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:
Deferring CR3 switch to C code means that we need to run more of the
kernel entry code with the user page-table. To do so, we need to:
- map more syscall, interrupt and exception
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
On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:
> Deferring CR3 switch to C code means that we need to run more of the
> kernel entry code with the user page-table. To do so, we need to:
>
> - map more syscall, interrupt and exception entry code into the user
>page-table
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
Version 2 addressing comments from Andy:
- paranoid_entry/exit is back to assembly code. This avoids having
a C version of SWAPGS and the need to disable stack-protector.
(remove patches 8, 9, 21 from v1).
- SAVE_AND_SWITCH_TO_KERNEL_CR3 and RESTORE_CR3 are removed from
paranoid_entry/exit
22 matches
Mail list logo
