How about performance when running with ASI?
How about performance when running with ASI?
How about performance when running kvm example or isolate other kernel data?
On 7/31/19 6:31 PM, Dario Faggioli wrote:
Hello all,
I know this is a bit of an old thread, so apologies for being late to
the party. :-)
And sorry for the late reply, I was away for a while.
I would have a question about this:
On 7/12/19 2:36 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2
Hello all,
I know this is a bit of an old thread, so apologies for being late to
the party. :-)
I would have a question about this:
> > > On 7/12/19 2:36 PM, Peter Zijlstra wrote:
> > > > On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre
> > > > wrote:
> > > > > On 7/12/19 1:44 PM, Pet
On Sun, Jul 14, 2019 at 08:06:12AM -0700, Andy Lutomirski wrote:
> On Fri, Jul 12, 2019 at 12:06 PM Peter Zijlstra wrote:
> >
> > On Fri, Jul 12, 2019 at 06:37:47PM +0200, Alexandre Chartre wrote:
> > > On 7/12/19 5:16 PM, Thomas Gleixner wrote:
> >
> > > > Right. If we decide to expose more parts
Alexandre,
On Mon, 15 Jul 2019, Alexandre Chartre wrote:
> On 7/12/19 9:48 PM, Thomas Gleixner wrote:
> > As I said before, come up with a list of possible usage scenarios and
> > protection scopes first and please take all the ideas other people have
> > with this into account. This includes PTI
On 7/12/19 9:48 PM, Thomas Gleixner wrote:
On Fri, 12 Jul 2019, Alexandre Chartre wrote:
On 7/12/19 5:16 PM, Thomas Gleixner wrote:
On Fri, 12 Jul 2019, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
And then we've fully replaced PTI.
So no, they'r
On 12.07.19 16:36, Andy Lutomirski wrote:
On Fri, Jul 12, 2019 at 6:45 AM Alexandre Chartre
wrote:
On 7/12/19 2:50 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
I think that's precisely what makes ASI and PTI different and independent.
PTI
On Fri, Jul 12, 2019 at 10:45:06AM -0600, Andy Lutomirski wrote:
>
>
> > On Jul 12, 2019, at 10:37 AM, Alexandre Chartre
> > wrote:
> >
> >
> >
> >> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
> >>> On Fri, 12 Jul 2019, Peter Zijlstra wrote:
> On Fri, Jul 12, 2019 at 01:56:44PM +0200, Al
On Fri, Jul 12, 2019 at 12:06 PM Peter Zijlstra wrote:
>
> On Fri, Jul 12, 2019 at 06:37:47PM +0200, Alexandre Chartre wrote:
> > On 7/12/19 5:16 PM, Thomas Gleixner wrote:
>
> > > Right. If we decide to expose more parts of the kernel mappings then
> > > that's
> > > just adding more stuff to th
On Fri, 12 Jul 2019, Alexandre Chartre wrote:
> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
> > On Fri, 12 Jul 2019, Peter Zijlstra wrote:
> > > On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
> > > And then we've fully replaced PTI.
> > >
> > > So no, they're not orthogonal.
> >
On Fri, Jul 12, 2019 at 06:37:47PM +0200, Alexandre Chartre wrote:
> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
> > Right. If we decide to expose more parts of the kernel mappings then that's
> > just adding more stuff to the existing user (PTI) map mechanics.
>
> If we expose more parts of the k
> On Jul 12, 2019, at 10:37 AM, Alexandre Chartre
> wrote:
>
>
>
>> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
>>> On Fri, 12 Jul 2019, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
I think that's precisely what makes ASI and PTI di
On 7/12/19 5:16 PM, Thomas Gleixner wrote:
On Fri, 12 Jul 2019, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
I think that's precisely what makes ASI and PTI different and independent.
PTI is just about switching between userland and kernel page-ta
On Fri, 12 Jul 2019, Alexandre Chartre wrote:
> On 7/12/19 12:44 PM, Thomas Gleixner wrote:
> > That ASI thing is just PTI on steroids.
> >
> > So why do we need two versions of the same thing? That's absolutely bonkers
> > and will just introduce subtle bugs and conflicting decisions all over the
On Fri, 12 Jul 2019, Alexandre Chartre wrote:
> On 7/12/19 3:51 PM, Dave Hansen wrote:
> > BTW, the PTI CR3 writes are not *strictly* about the interrupt coming
> > from user vs. kernel. It's tricky because there's a window both in the
> > entry and exit code where you are in the kernel but have a
On Fri, Jul 12, 2019 at 06:54:22AM -0700, Dave Hansen wrote:
> On 7/12/19 5:50 AM, Peter Zijlstra wrote:
> > PTI is not mapping kernel space to avoid speculation
> > crap (meltdown).
> > ASI is not mapping part of kernel space to avoid (different) speculation
> > crap (MDS).
>
On Fri, 12 Jul 2019, Peter Zijlstra wrote:
> On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
>
> > I think that's precisely what makes ASI and PTI different and independent.
> > PTI is just about switching between userland and kernel page-tables, while
> > ASI is about switching
On Fri, Jul 12, 2019 at 6:45 AM Alexandre Chartre
wrote:
>
>
> On 7/12/19 2:50 PM, Peter Zijlstra wrote:
> > On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
> >
> >> I think that's precisely what makes ASI and PTI different and independent.
> >> PTI is just about switching betwe
On 7/12/19 3:51 PM, Dave Hansen wrote:
On 7/12/19 1:09 AM, Alexandre Chartre wrote:
On 7/12/19 12:38 AM, Dave Hansen wrote:
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.
We don't map all per-cpu areas, but only the per-cp
On 7/12/19 6:43 AM, Alexandre Chartre wrote:
> The current approach is assuming that anything in the user address space
> can be sensitive, and so the user address space shouldn't be mapped in ASI.
Is this universally true?
There's certainly *some* mitigation provided by SMAP that would allow
use
On 7/12/19 5:50 AM, Peter Zijlstra wrote:
> PTI is not mapping kernel space to avoid speculation crap
> (meltdown).
> ASI is not mapping part of kernel space to avoid (different) speculation crap
> (MDS).
>
> See how very similar they are?
That's an interesting point.
I'd a
On 7/12/19 3:07 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 02:47:23PM +0200, Alexandre Chartre wrote:
On 7/12/19 2:36 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre wrote:
On 7/12/19 1:44 PM, Peter Zijlstra wrote:
AFAIK3 this wants/needs to be
On 7/12/19 1:09 AM, Alexandre Chartre wrote:
> On 7/12/19 12:38 AM, Dave Hansen wrote:
>> 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.
>
> We don't map all per-cpu areas, but only the per-cpu variables we need. ASI
> code us
On 7/12/19 2:50 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
I think that's precisely what makes ASI and PTI different and independent.
PTI is just about switching between userland and kernel page-tables, while
ASI is about switching page-table
On Fri, Jul 12, 2019 at 02:47:23PM +0200, Alexandre Chartre wrote:
> On 7/12/19 2:36 PM, Peter Zijlstra wrote:
> > On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre wrote:
> > > On 7/12/19 1:44 PM, Peter Zijlstra wrote:
> >
> > > > AFAIK3 this wants/needs to be combined with core-schedul
On 7/12/19 2:36 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre wrote:
On 7/12/19 1:44 PM, Peter Zijlstra wrote:
AFAIK3 this wants/needs to be combined with core-scheduling to be
useful, but not a single mention of that is anywhere.
No. This is actual
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
> I think that's precisely what makes ASI and PTI different and independent.
> PTI is just about switching between userland and kernel page-tables, while
> ASI is about switching page-table inside the kernel. You can have ASI witho
On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre wrote:
> On 7/12/19 1:44 PM, Peter Zijlstra wrote:
> > AFAIK3 this wants/needs to be combined with core-scheduling to be
> > useful, but not a single mention of that is anywhere.
>
> No. This is actually an alternative to core-scheduling
On 7/12/19 1:44 PM, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 04:25:12PM +0200, Alexandre Chartre wrote:
Kernel Address Space Isolation aims to use address spaces to isolate some
parts of the kernel (for example KVM) to prevent leaking sensitive data
between hyper-threads under speculative
On 7/12/19 12:44 PM, Thomas Gleixner wrote:
On Thu, 11 Jul 2019, Dave Hansen wrote:
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 (be
On Thu, Jul 11, 2019 at 04:25:12PM +0200, Alexandre Chartre wrote:
> Kernel Address Space Isolation aims to use address spaces to isolate some
> parts of the kernel (for example KVM) to prevent leaking sensitive data
> between hyper-threads under speculative execution attacks. You can refer
> to th
On Thu, 11 Jul 2019, Dave Hansen wrote:
> 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)
>
On 7/12/19 12:38 AM, Dave Hansen wrote:
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 c
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)
> .
And I've just noticed that I've messed up the subject of the cover letter.
There are 26 patches, not 27. So it should have been 00/26 not 00/27.
Sorry about that.
alex.
On 7/11/19 4:25 PM, Alexandre Chartre wrote:
Hi,
This is version 2 of the "KVM Address Space Isolation" RFC. The code
has
Hi,
This is version 2 of the "KVM Address Space Isolation" RFC. The code
has been completely changed compared to v1 and it now provides a generic
kernel framework which provides Address Space Isolation; and KVM is now
a simple consumer of that framework. That's why the RFC title has been
changed f
38 matches
Mail list logo
