lkml.org 
[lkml]   [2018]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch V2 21/28] x86/speculation: Prepare for conditional IBPB in switch_mm()
From
Date


> On Nov 25, 2018, at 2:20 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Sun, 25 Nov 2018, Andi Kleen wrote:
>
>>> The current check whether two tasks belong to the same context is using the
>>> tasks context id. While correct, it's simpler to use the mm pointer because
>>> it allows to mangle the TIF_SPEC_IB bit into it. The context id based
>>> mechanism requires extra storage, which creates worse code.
>>
>> [We tried similar in some really early versions, but it was replaced
>> with the context id later.]
>>
>> One issue with using the pointer is that the pointer can be reused
>> when the original mm_struct is freed, and then gets reallocated
>> immediately to an attacker. Then the attacker may avoid the IBPB.
>>
>> Given it's probably hard to generate any reasonable leak bandwidth with
>> such a complex scenario, but it still seemed better to close the hole.
>
> Sorry, but that's really a purely academic exercise.
>
>

I would guess that it’s actually very easy to force mm_struct* reuse. Don’t the various allocators try to allocate hot memory? There’s nothing hotter than a just-freed allocation of the same size.

Can someone explain the actual problem with ctx_id? If you just need an extra bit, how about:

2*ctx_id vs 2*ctx_id+1

Or any of the many variants of approximately the same thing?

—Andy
\
 
 \ /
  Last update: 2018-11-26 00:04    [W:0.226 / U:29.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site