On 4/5/19 10:27 AM, Andy Lutomirski wrote:
> At the risk of asking stupid questions: we already have a mechanism for this:
> highmem. Can we enable highmem on x86_64, maybe with some heuristics to make
> it work well?
>
I proposed using highmem infrastructure for xpfo in my cover letter as
On Fri, Apr 05, 2019 at 10:27:05AM -0600, Andy Lutomirski wrote:
> At the risk of asking stupid questions: we already have a mechanism
> for this: highmem. Can we enable highmem on x86_64, maybe with some
> heuristics to make it work well?
That's what I said; but note that I'm still not
> On Apr 5, 2019, at 9:56 AM, Tycho Andersen wrote:
>
>> On Fri, Apr 05, 2019 at 09:24:50AM -0600, Andy Lutomirski wrote:
>>
>>
>>> On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
>>>
>>> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
> process. Is that an acceptable trade-off?
You are
> On Apr 5, 2019, at 10:01 AM, Dave Hansen wrote:
>
> On 4/5/19 8:24 AM, Andy Lutomirski wrote:
>>> Sounds like we need a mechanism that will do the deferred XPFO TLB
>>> flushes whenever the kernel is entered, and not _just_ at context
>>> switch time. This permits an app to run in
On 4/5/19 8:24 AM, Andy Lutomirski wrote:
>> Sounds like we need a mechanism that will do the deferred XPFO TLB
>> flushes whenever the kernel is entered, and not _just_ at context
>> switch time. This permits an app to run in userspace with stale
>> kernel TLB entries as long as it wants...
On 4/5/19 9:24 AM, Andy Lutomirski wrote:
>
>
>> On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
>>
>> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
process. Is that an acceptable trade-off?
>>> You are not seriously asking whether creating a user controllable ret2dir
>>> attack window is a
On Fri, Apr 05, 2019 at 09:24:50AM -0600, Andy Lutomirski wrote:
>
>
> > On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
> >
> > On 4/5/19 12:17 AM, Thomas Gleixner wrote:
> >>> process. Is that an acceptable trade-off?
> >> You are not seriously asking whether creating a user controllable
On 4/5/19 8:44 AM, Dave Hansen wrote:
> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
>>> process. Is that an acceptable trade-off?
>> You are not seriously asking whether creating a user controllable ret2dir
>> attack window is a acceptable trade-off? April 1st was a few days ago.
>
> Well, let's
> On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
>
> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
>>> process. Is that an acceptable trade-off?
>> You are not seriously asking whether creating a user controllable ret2dir
>> attack window is a acceptable trade-off? April 1st was a few days ago.
>
>>> On Apr 4, 2019, at 4:55 PM, Khalid Aziz wrote:
>>>
>>> On 4/3/19 10:10 PM, Andy Lutomirski wrote:
>>> On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
>>>
>>> XPFO flushes kernel space TLB entries for pages that are now mapped
>>> in userspace on not only the current CPU but also all
On 4/5/19 12:17 AM, Thomas Gleixner wrote:
>> process. Is that an acceptable trade-off?
> You are not seriously asking whether creating a user controllable ret2dir
> attack window is a acceptable trade-off? April 1st was a few days ago.
Well, let's not forget that this set at least takes us from
On Thu, 4 Apr 2019, Khalid Aziz wrote:
> When xpfo unmaps a page from physmap only (after mapping the page in
> userspace in response to an allocation request from userspace) on one
> processor, there is a small window of opportunity for ret2dir attack on
> other cpus until the TLB entry in
On 4/3/19 10:10 PM, Andy Lutomirski wrote:
> On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
>>
>> XPFO flushes kernel space TLB entries for pages that are now mapped
>> in userspace on not only the current CPU but also all other CPUs
>> synchronously. Processes on each core allocating pages
On Wed, Apr 03, 2019 at 11:34:13AM -0600, Khalid Aziz wrote:
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 999d6d8f0bef..cc806a01a0eb 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -37,6 +37,20 @@
> */
> #define LAST_USER_MM_IBPB0x1UL
>
> +/*
> + * A TLB
On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
>
> XPFO flushes kernel space TLB entries for pages that are now mapped
> in userspace on not only the current CPU but also all other CPUs
> synchronously. Processes on each core allocating pages causes a
> flood of IPI messages to all other
XPFO flushes kernel space TLB entries for pages that are now mapped
in userspace on not only the current CPU but also all other CPUs
synchronously. Processes on each core allocating pages causes a
flood of IPI messages to all other cores to flush TLB entries.
Many of these messages are to flush
16 matches
Mail list logo
