On 1/10/19 1:09 PM, Khalid Aziz wrote:
I am continuing to build on the work Juerg, Tycho and Julian have done
on XPFO. After the last round of updates, we were seeing very
significant performance penalties when stale TLB entries were flushed
actively after an XPFO TLB update. Benchmark for measur
On 1/16/19 7:56 AM, Julian Stecklina wrote:
> Khalid Aziz writes:
>
>> I am continuing to build on the work Juerg, Tycho and Julian have done
>> on XPFO.
>
> Awesome!
>
>> A rogue process can launch a ret2dir attack only from a CPU that has
>> dual mapping for its pages in physmap in its TLB. W
Khalid Aziz writes:
> I am continuing to build on the work Juerg, Tycho and Julian have done
> on XPFO.
Awesome!
> A rogue process can launch a ret2dir attack only from a CPU that has
> dual mapping for its pages in physmap in its TLB. We can hence defer
> TLB flush on a CPU until a process tha
On 1/10/19 1:09 PM, Khalid Aziz wrote:
I am continuing to build on the work Juerg, Tycho and Julian have done
on XPFO. After the last round of updates, we were seeing very
significant performance penalties when stale TLB entries were flushed
actively after an XPFO TLB update. Benchmark for measur
On 1/11/19 2:06 PM, Andy Lutomirski wrote:
> On Fri, Jan 11, 2019 at 12:42 PM Dave Hansen wrote:
>>
The second process could easily have the page's old TLB entry. It could
abuse that entry as long as that CPU doesn't context switch
(switch_mm_irqs_off()) or otherwise flush the TLB
On 1/11/19 1:42 PM, Dave Hansen wrote:
>>> The second process could easily have the page's old TLB entry. It could
>>> abuse that entry as long as that CPU doesn't context switch
>>> (switch_mm_irqs_off()) or otherwise flush the TLB entry.
>>
>> That is an interesting scenario. Working through thi
On 1/10/19 5:44 PM, Andy Lutomirski wrote:
> On Thu, Jan 10, 2019 at 3:07 PM Kees Cook wrote:
>>
>> On Thu, Jan 10, 2019 at 1:10 PM Khalid Aziz wrote:
>>> I implemented a solution to reduce performance penalty and
>>> that has had large impact. When XPFO code flushes stale TLB entries,
>>> it doe
On Fri, Jan 11, 2019 at 12:42 PM Dave Hansen wrote:
>
> >> The second process could easily have the page's old TLB entry. It could
> >> abuse that entry as long as that CPU doesn't context switch
> >> (switch_mm_irqs_off()) or otherwise flush the TLB entry.
> >
> > That is an interesting scenario
>> The second process could easily have the page's old TLB entry. It could
>> abuse that entry as long as that CPU doesn't context switch
>> (switch_mm_irqs_off()) or otherwise flush the TLB entry.
>
> That is an interesting scenario. Working through this scenario, physmap
> TLB entry for a page
Hi Dave,
Thanks for looking at this and providing feedback.
On 1/10/19 4:40 PM, Dave Hansen wrote:
> First of all, thanks for picking this back up. It looks to be going in
> a very positive direction!
>
> On 1/10/19 1:09 PM, Khalid Aziz wrote:
>> I implemented a solution to reduce performance p
On Thu, Jan 10, 2019 at 03:40:04PM -0800, Dave Hansen wrote:
> Anything else you do will have *some* reduced mitigation value, which
> isn't a deal-breaker (to me at least). Some ideas:
>
> Take a look at the SWITCH_TO_KERNEL_CR3 in head_64.S. Every time that
> gets called, we've (potentially) j
On Thu, Jan 10, 2019 at 3:07 PM Kees Cook wrote:
>
> On Thu, Jan 10, 2019 at 1:10 PM Khalid Aziz wrote:
> > I implemented a solution to reduce performance penalty and
> > that has had large impact. When XPFO code flushes stale TLB entries,
> > it does so for all CPUs on the system which may inclu
Thanks for looking this over.
On 1/10/19 4:07 PM, Kees Cook wrote:
> On Thu, Jan 10, 2019 at 1:10 PM Khalid Aziz wrote:
>> I implemented a solution to reduce performance penalty and
>> that has had large impact. When XPFO code flushes stale TLB entries,
>> it does so for all CPUs on the system wh
First of all, thanks for picking this back up. It looks to be going in
a very positive direction!
On 1/10/19 1:09 PM, Khalid Aziz wrote:
> I implemented a solution to reduce performance penalty and
> that has had large impact. When XPFO code flushes stale TLB entries,
> it does so for all CPUs on
On Thu, Jan 10, 2019 at 1:10 PM Khalid Aziz wrote:
> I implemented a solution to reduce performance penalty and
> that has had large impact. When XPFO code flushes stale TLB entries,
> it does so for all CPUs on the system which may include CPUs that
> may not have any matching TLB entries or may
I am continuing to build on the work Juerg, Tycho and Julian have done
on XPFO. After the last round of updates, we were seeing very
significant performance penalties when stale TLB entries were flushed
actively after an XPFO TLB update. Benchmark for measuring performance
is kernel build using par
16 matches
Mail list logo
