On Wed, Oct 24, 2018 at 04:30:42PM +0530, Khalid Aziz wrote:
> On 10/15/2018 01:37 PM, Khalid Aziz wrote:
> > On 09/24/2018 08:45 AM, Stecklina, Julian wrote:
> > > I didn't test the version with TLB flushes, because it's clear that the
> > > overhead is so bad that no one wants to use this.
> >
On Wed, Oct 24, 2018 at 04:30:42PM +0530, Khalid Aziz wrote:
> On 10/15/2018 01:37 PM, Khalid Aziz wrote:
> > On 09/24/2018 08:45 AM, Stecklina, Julian wrote:
> > > I didn't test the version with TLB flushes, because it's clear that the
> > > overhead is so bad that no one wants to use this.
> >
On 10/15/2018 01:37 PM, Khalid Aziz wrote:
On 09/24/2018 08:45 AM, Stecklina, Julian wrote:
I didn't test the version with TLB flushes, because it's clear that the
overhead is so bad that no one wants to use this.
I don't think we can ignore the vulnerability caused by not flushing
stale TLB
On 10/15/2018 01:37 PM, Khalid Aziz wrote:
On 09/24/2018 08:45 AM, Stecklina, Julian wrote:
I didn't test the version with TLB flushes, because it's clear that the
overhead is so bad that no one wants to use this.
I don't think we can ignore the vulnerability caused by not flushing
stale TLB
On 09/24/2018 08:45 AM, Stecklina, Julian wrote:
I didn't test the version with TLB flushes, because it's clear that the
overhead is so bad that no one wants to use this.
I don't think we can ignore the vulnerability caused by not flushing
stale TLB entries. On a mostly idle system, TLB
On 09/24/2018 08:45 AM, Stecklina, Julian wrote:
I didn't test the version with TLB flushes, because it's clear that the
overhead is so bad that no one wants to use this.
I don't think we can ignore the vulnerability caused by not flushing
stale TLB entries. On a mostly idle system, TLB
On Sun, 2018-09-23 at 12:33 +1000, Balbir Singh wrote:
> > And in so doing, significantly reduces the amount of non-kernel
> data
> > vulnerable to speculative execution attacks against the kernel.
> > (and reduces what data can be loaded into the L1 data cache while
> > in kernel mode, to be
On Sun, 2018-09-23 at 12:33 +1000, Balbir Singh wrote:
> > And in so doing, significantly reduces the amount of non-kernel
> data
> > vulnerable to speculative execution attacks against the kernel.
> > (and reduces what data can be loaded into the L1 data cache while
> > in kernel mode, to be
On Tue, 2018-09-18 at 17:00 -0600, Khalid Aziz wrote:
> I tested the kernel with this new code. When booted without
> "xpfotlbflush",
> there is no meaningful change in system time with kernel compile.
That's good news! So the lock optimizations seem to help.
> Kernel
> locks up during bootup
On Tue, 2018-09-18 at 17:00 -0600, Khalid Aziz wrote:
> I tested the kernel with this new code. When booted without
> "xpfotlbflush",
> there is no meaningful change in system time with kernel compile.
That's good news! So the lock optimizations seem to help.
> Kernel
> locks up during bootup
On Wed, Sep 19, 2018 at 08:43:07AM -0700, Jonathan Adams wrote:
> (apologies again; resending due to formatting issues)
> On Tue, Sep 18, 2018 at 6:03 PM Balbir Singh wrote:
> >
> > On Mon, Aug 20, 2018 at 09:52:19PM +, Woodhouse, David wrote:
> > > On Mon, 2018-08-20 at 14:48 -0700, Linus
On Wed, Sep 19, 2018 at 08:43:07AM -0700, Jonathan Adams wrote:
> (apologies again; resending due to formatting issues)
> On Tue, Sep 18, 2018 at 6:03 PM Balbir Singh wrote:
> >
> > On Mon, Aug 20, 2018 at 09:52:19PM +, Woodhouse, David wrote:
> > > On Mon, 2018-08-20 at 14:48 -0700, Linus
(apologies again; resending due to formatting issues)
On Tue, Sep 18, 2018 at 6:03 PM Balbir Singh wrote:
>
> On Mon, Aug 20, 2018 at 09:52:19PM +, Woodhouse, David wrote:
> > On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
> > >
> > > Of course, after the long (and entirely
(apologies again; resending due to formatting issues)
On Tue, Sep 18, 2018 at 6:03 PM Balbir Singh wrote:
>
> On Mon, Aug 20, 2018 at 09:52:19PM +, Woodhouse, David wrote:
> > On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
> > >
> > > Of course, after the long (and entirely
On Mon, Aug 20, 2018 at 09:52:19PM +, Woodhouse, David wrote:
> On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
> >
> > Of course, after the long (and entirely unrelated) discussion about
> > the TLB flushing bug we had, I'm starting to worry about my own
> > competence, and maybe
On Mon, Aug 20, 2018 at 09:52:19PM +, Woodhouse, David wrote:
> On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
> >
> > Of course, after the long (and entirely unrelated) discussion about
> > the TLB flushing bug we had, I'm starting to worry about my own
> > competence, and maybe
On 09/17/2018 03:51 AM, Julian Stecklina wrote:
> Khalid Aziz writes:
>
>> I ran tests with your updated code and gathered lock statistics. Change in
>> system time for "make -j60" was in the noise margin (It actually went up by
>> about 2%). There is some contention on xpfo_lock. Average wait
On 09/17/2018 03:51 AM, Julian Stecklina wrote:
> Khalid Aziz writes:
>
>> I ran tests with your updated code and gathered lock statistics. Change in
>> system time for "make -j60" was in the noise margin (It actually went up by
>> about 2%). There is some contention on xpfo_lock. Average wait
On Mon, Sep 17, 2018 at 12:01:02PM +0200, Julian Stecklina wrote:
> Juerg Haefliger writes:
>
> >> I've updated my XPFO branch[1] to make some of the debugging optional
> >> and also integrated the XPFO bookkeeping with struct page, instead of
> >> requiring CONFIG_PAGE_EXTENSION, which removes
On Mon, Sep 17, 2018 at 12:01:02PM +0200, Julian Stecklina wrote:
> Juerg Haefliger writes:
>
> >> I've updated my XPFO branch[1] to make some of the debugging optional
> >> and also integrated the XPFO bookkeeping with struct page, instead of
> >> requiring CONFIG_PAGE_EXTENSION, which removes
On Mon, Sep 17, 2018 at 12:01:02PM +0200, Julian Stecklina wrote:
> Juerg Haefliger writes:
>
> >> I've updated my XPFO branch[1] to make some of the debugging optional
> >> and also integrated the XPFO bookkeeping with struct page, instead of
> >> requiring CONFIG_PAGE_EXTENSION, which removes
On Mon, Sep 17, 2018 at 12:01:02PM +0200, Julian Stecklina wrote:
> Juerg Haefliger writes:
>
> >> I've updated my XPFO branch[1] to make some of the debugging optional
> >> and also integrated the XPFO bookkeeping with struct page, instead of
> >> requiring CONFIG_PAGE_EXTENSION, which removes
Juerg Haefliger writes:
>> I've updated my XPFO branch[1] to make some of the debugging optional
>> and also integrated the XPFO bookkeeping with struct page, instead of
>> requiring CONFIG_PAGE_EXTENSION, which removes some checks in the hot
>> path.
>
> FWIW, that was my original design but
Juerg Haefliger writes:
>> I've updated my XPFO branch[1] to make some of the debugging optional
>> and also integrated the XPFO bookkeeping with struct page, instead of
>> requiring CONFIG_PAGE_EXTENSION, which removes some checks in the hot
>> path.
>
> FWIW, that was my original design but
Khalid Aziz writes:
> I ran tests with your updated code and gathered lock statistics. Change in
> system time for "make -j60" was in the noise margin (It actually went up by
> about 2%). There is some contention on xpfo_lock. Average wait time does not
> look high compared to other locks. Max
Khalid Aziz writes:
> I ran tests with your updated code and gathered lock statistics. Change in
> system time for "make -j60" was in the noise margin (It actually went up by
> about 2%). There is some contention on xpfo_lock. Average wait time does not
> look high compared to other locks. Max
On 09/12/2018 09:37 AM, Julian Stecklina wrote:
> Julian Stecklina writes:
>
>> Linus Torvalds writes:
>>
>>> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina
>>> wrote:
I've been spending some cycles on the XPFO patch set this week. For the
patch set as it was posted for
On 09/12/2018 09:37 AM, Julian Stecklina wrote:
> Julian Stecklina writes:
>
>> Linus Torvalds writes:
>>
>>> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina
>>> wrote:
I've been spending some cycles on the XPFO patch set this week. For the
patch set as it was posted for
On Wed, Sep 12, 2018 at 5:37 PM, Julian Stecklina wrote:
> Julian Stecklina writes:
>
>> Linus Torvalds writes:
>>
>>> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina
>>> wrote:
I've been spending some cycles on the XPFO patch set this week. For the
patch set as it was posted
On Wed, Sep 12, 2018 at 5:37 PM, Julian Stecklina wrote:
> Julian Stecklina writes:
>
>> Linus Torvalds writes:
>>
>>> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina
>>> wrote:
I've been spending some cycles on the XPFO patch set this week. For the
patch set as it was posted
Julian Stecklina writes:
> Linus Torvalds writes:
>
>> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
>>>
>>> I've been spending some cycles on the XPFO patch set this week. For the
>>> patch set as it was posted for v4.13, the performance overhead of
>>> compiling a Linux kernel is
Julian Stecklina writes:
> Linus Torvalds writes:
>
>> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
>>>
>>> I've been spending some cycles on the XPFO patch set this week. For the
>>> patch set as it was posted for v4.13, the performance overhead of
>>> compiling a Linux kernel is
On 08/30/2018 10:00 AM, Julian Stecklina wrote:
Hey everyone,
On Mon, 20 Aug 2018 15:27 Linus Torvalds wrote:
On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
It's the *kernel* we don't want being able to access those pages,
because of the multitude of unfixable cache load gadgets.
On 08/30/2018 10:00 AM, Julian Stecklina wrote:
Hey everyone,
On Mon, 20 Aug 2018 15:27 Linus Torvalds wrote:
On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
It's the *kernel* we don't want being able to access those pages,
because of the multitude of unfixable cache load gadgets.
Andi Kleen writes:
> On Sat, Sep 01, 2018 at 02:38:43PM -0700, Linus Torvalds wrote:
>> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
>> >
>> > I've been spending some cycles on the XPFO patch set this week. For the
>> > patch set as it was posted for v4.13, the performance overhead
Andi Kleen writes:
> On Sat, Sep 01, 2018 at 02:38:43PM -0700, Linus Torvalds wrote:
>> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
>> >
>> > I've been spending some cycles on the XPFO patch set this week. For the
>> > patch set as it was posted for v4.13, the performance overhead
On Sat, Sep 01, 2018 at 06:33:22PM -0400, Wes Turner wrote:
>Speaking of pages and slowdowns,
>is there a better place to ask this question:
>From "'Turning Tables' shared page tables vuln":
>"""
>'New "Turning Tables" Technique Bypasses All Windows Kernel Mitigations'
>
>
On Sat, Sep 01, 2018 at 06:33:22PM -0400, Wes Turner wrote:
>Speaking of pages and slowdowns,
>is there a better place to ask this question:
>From "'Turning Tables' shared page tables vuln":
>"""
>'New "Turning Tables" Technique Bypasses All Windows Kernel Mitigations'
>
>
On Sat, Sep 01, 2018 at 02:38:43PM -0700, Linus Torvalds wrote:
> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
> >
> > I've been spending some cycles on the XPFO patch set this week. For the
> > patch set as it was posted for v4.13, the performance overhead of
> > compiling a Linux
On Sat, Sep 01, 2018 at 02:38:43PM -0700, Linus Torvalds wrote:
> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
> >
> > I've been spending some cycles on the XPFO patch set this week. For the
> > patch set as it was posted for v4.13, the performance overhead of
> > compiling a Linux
Linus Torvalds writes:
> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
>>
>> I've been spending some cycles on the XPFO patch set this week. For the
>> patch set as it was posted for v4.13, the performance overhead of
>> compiling a Linux kernel is ~40% on x86_64[1]. The overhead
Linus Torvalds writes:
> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
>>
>> I've been spending some cycles on the XPFO patch set this week. For the
>> patch set as it was posted for v4.13, the performance overhead of
>> compiling a Linux kernel is ~40% on x86_64[1]. The overhead
On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
>
> I've been spending some cycles on the XPFO patch set this week. For the
> patch set as it was posted for v4.13, the performance overhead of
> compiling a Linux kernel is ~40% on x86_64[1]. The overhead comes almost
> completely from TLB
On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote:
>
> I've been spending some cycles on the XPFO patch set this week. For the
> patch set as it was posted for v4.13, the performance overhead of
> compiling a Linux kernel is ~40% on x86_64[1]. The overhead comes almost
> completely from TLB
On Thu, Aug 30, 2018 at 06:00:51PM +0200, Julian Stecklina wrote:
> Hey everyone,
>
> On Mon, 20 Aug 2018 15:27 Linus Torvalds
> wrote:
> > On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
> >>
> >> It's the *kernel* we don't want being able to access those pages,
> >> because of the
On Thu, Aug 30, 2018 at 06:00:51PM +0200, Julian Stecklina wrote:
> Hey everyone,
>
> On Mon, 20 Aug 2018 15:27 Linus Torvalds
> wrote:
> > On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
> >>
> >> It's the *kernel* we don't want being able to access those pages,
> >> because of the
On Mon, 2018-08-20 at 21:52 +, Woodhouse, David wrote:
> On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
> >
> > Of course, after the long (and entirely unrelated) discussion about
> > the TLB flushing bug we had, I'm starting to worry about my own
> > competence, and maybe I'm
On Mon, 2018-08-20 at 21:52 +, Woodhouse, David wrote:
> On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
> >
> > Of course, after the long (and entirely unrelated) discussion about
> > the TLB flushing bug we had, I'm starting to worry about my own
> > competence, and maybe I'm
Hey everyone,
On Mon, 20 Aug 2018 15:27 Linus Torvalds wrote:
> On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
>>
>> It's the *kernel* we don't want being able to access those pages,
>> because of the multitude of unfixable cache load gadgets.
>
> Ahh.
>
> I guess the proof is in the
Hey everyone,
On Mon, 20 Aug 2018 15:27 Linus Torvalds wrote:
> On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
>>
>> It's the *kernel* we don't want being able to access those pages,
>> because of the multitude of unfixable cache load gadgets.
>
> Ahh.
>
> I guess the proof is in the
> On 21 Aug 2018, at 17:22, David Woodhouse wrote:
>
> On Tue, 2018-08-21 at 17:01 +0300, Liran Alon wrote:
>>
>>> On 21 Aug 2018, at 12:57, David Woodhouse
>> wrote:
>>>
>>> Another alternative... I'm told POWER8 does an interesting thing
>> with
>>> hyperthreading and gang scheduling
> On 21 Aug 2018, at 17:22, David Woodhouse wrote:
>
> On Tue, 2018-08-21 at 17:01 +0300, Liran Alon wrote:
>>
>>> On 21 Aug 2018, at 12:57, David Woodhouse
>> wrote:
>>>
>>> Another alternative... I'm told POWER8 does an interesting thing
>> with
>>> hyperthreading and gang scheduling
On Tue, 2018-08-21 at 17:01 +0300, Liran Alon wrote:
>
> > On 21 Aug 2018, at 12:57, David Woodhouse
> wrote:
> >
> > Another alternative... I'm told POWER8 does an interesting thing
> with
> > hyperthreading and gang scheduling for KVM. The host kernel doesn't
> > actually *see* the
On Tue, 2018-08-21 at 17:01 +0300, Liran Alon wrote:
>
> > On 21 Aug 2018, at 12:57, David Woodhouse
> wrote:
> >
> > Another alternative... I'm told POWER8 does an interesting thing
> with
> > hyperthreading and gang scheduling for KVM. The host kernel doesn't
> > actually *see* the
> On 21 Aug 2018, at 12:57, David Woodhouse wrote:
>
> Another alternative... I'm told POWER8 does an interesting thing with
> hyperthreading and gang scheduling for KVM. The host kernel doesn't
> actually *see* the hyperthreads at all, and KVM just launches the full
> set of siblings when it
> On 21 Aug 2018, at 12:57, David Woodhouse wrote:
>
> Another alternative... I'm told POWER8 does an interesting thing with
> hyperthreading and gang scheduling for KVM. The host kernel doesn't
> actually *see* the hyperthreads at all, and KVM just launches the full
> set of siblings when it
On Mon, 2018-08-20 at 15:27 -0700, Linus Torvalds wrote:
> On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
> >
> > It's the *kernel* we don't want being able to access those pages,
> > because of the multitude of unfixable cache load gadgets.
>
> Ahh.
>
> I guess the proof is in the
On Mon, 2018-08-20 at 15:27 -0700, Linus Torvalds wrote:
> On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
> >
> > It's the *kernel* we don't want being able to access those pages,
> > because of the multitude of unfixable cache load gadgets.
>
> Ahh.
>
> I guess the proof is in the
On Mon, Aug 20, 2018 at 4:27 PM Dave Hansen wrote:
>
> You're right that we could have a full physmap that we switch to for
> kmap()-like access to user pages. But, the real problem is
> transitioning pages from kernel to user usage since it requires shooting
> down the old kernel mappings for
On Mon, Aug 20, 2018 at 4:27 PM Dave Hansen wrote:
>
> You're right that we could have a full physmap that we switch to for
> kmap()-like access to user pages. But, the real problem is
> transitioning pages from kernel to user usage since it requires shooting
> down the old kernel mappings for
On 08/20/2018 04:14 PM, David Woodhouse wrote:
> If you need the physmap, then rather than manually mapping with 4KiB
> pages, you just switch. Having first ensured that no malicious guest or
> userspace is running on a sibling, of course.
The problem is determining when "you need the physmap".
On 08/20/2018 04:14 PM, David Woodhouse wrote:
> If you need the physmap, then rather than manually mapping with 4KiB
> pages, you just switch. Having first ensured that no malicious guest or
> userspace is running on a sibling, of course.
The problem is determining when "you need the physmap".
On Mon, 2018-08-20 at 15:59 -0700, Dave Hansen wrote:
> On 08/20/2018 03:35 PM, Tycho Andersen wrote:
> > Since meltdown hit, I haven't worked seriously on understand and
> > implementing his suggestions, in part because it wasn't clear to me
> > what pieces of the infrastructure we might be
On Mon, 2018-08-20 at 15:59 -0700, Dave Hansen wrote:
> On 08/20/2018 03:35 PM, Tycho Andersen wrote:
> > Since meltdown hit, I haven't worked seriously on understand and
> > implementing his suggestions, in part because it wasn't clear to me
> > what pieces of the infrastructure we might be
On 08/20/2018 03:35 PM, Tycho Andersen wrote:
> Since meltdown hit, I haven't worked seriously on understand and
> implementing his suggestions, in part because it wasn't clear to me
> what pieces of the infrastructure we might be able to re-use. Someone
> who knows more about mm/ might be able to
On 08/20/2018 03:35 PM, Tycho Andersen wrote:
> Since meltdown hit, I haven't worked seriously on understand and
> implementing his suggestions, in part because it wasn't clear to me
> what pieces of the infrastructure we might be able to re-use. Someone
> who knows more about mm/ might be able to
On Mon, Aug 20, 2018 at 03:27:52PM -0700, Linus Torvalds wrote:
> On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
> >
> > It's the *kernel* we don't want being able to access those pages,
> > because of the multitude of unfixable cache load gadgets.
>
> Ahh.
>
> I guess the proof is in
On Mon, Aug 20, 2018 at 03:27:52PM -0700, Linus Torvalds wrote:
> On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
> >
> > It's the *kernel* we don't want being able to access those pages,
> > because of the multitude of unfixable cache load gadgets.
>
> Ahh.
>
> I guess the proof is in
On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
>
> It's the *kernel* we don't want being able to access those pages,
> because of the multitude of unfixable cache load gadgets.
Ahh.
I guess the proof is in the pudding. Did somebody try to forward-port
that patch set and see what the
On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote:
>
> It's the *kernel* we don't want being able to access those pages,
> because of the multitude of unfixable cache load gadgets.
Ahh.
I guess the proof is in the pudding. Did somebody try to forward-port
that patch set and see what the
On Mon, Aug 20, 2018 at 2:52 PM, Woodhouse, David wrote:
> On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
>>
>> Of course, after the long (and entirely unrelated) discussion about
>> the TLB flushing bug we had, I'm starting to worry about my own
>> competence, and maybe I'm missing
On Mon, Aug 20, 2018 at 2:52 PM, Woodhouse, David wrote:
> On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
>>
>> Of course, after the long (and entirely unrelated) discussion about
>> the TLB flushing bug we had, I'm starting to worry about my own
>> competence, and maybe I'm missing
On Mon, Aug 20, 2018 at 2:26 PM Konrad Rzeszutek Wilk
wrote:
>
> See eXclusive Page Frame Ownership (https://lwn.net/Articles/700606/) which
> was posted
> way back in in 2016..
Ok, so my gut feel is that the above was reasonable within the context
of 2016, but that the XPFO model is completely
On Mon, Aug 20, 2018 at 2:26 PM Konrad Rzeszutek Wilk
wrote:
>
> See eXclusive Page Frame Ownership (https://lwn.net/Articles/700606/) which
> was posted
> way back in in 2016..
Ok, so my gut feel is that the above was reasonable within the context
of 2016, but that the XPFO model is completely
Hi!
See eXclusive Page Frame Ownership (https://lwn.net/Articles/700606/) which was
posted
way back in in 2016..
In the last couple of months there has been a slew of CPU issues that have
complicated
a lot of things. The latest - L1TF - is still fresh in folks's mind and it is
especially acute
Hi!
See eXclusive Page Frame Ownership (https://lwn.net/Articles/700606/) which was
posted
way back in in 2016..
In the last couple of months there has been a slew of CPU issues that have
complicated
a lot of things. The latest - L1TF - is still fresh in folks's mind and it is
especially acute
76 matches
Mail list logo
