Re: [Xen-devel] [PATCH v2 2/2] x86/xpti: don't map stack guard pages

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.03.18 at 18:33, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 02/03/18 14:35, Jan Beulich wrote:
>> Other than for the main mappings, don't even do this in release builds,
>> as there are no huge page shattering concerns here.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, although I think
> somewhere (even if its only the commit message) might want to identify
> that this is safe to the AMD triple fault issue, because even if someone
> enabled XPTI, it only takes effect for PV guests, rather than HVM.  Also,

I've added

"Note that since we don't run on the restructed page tables while HVM
 guests execute, the non-present mappings won't trigger the triple fault
 issue AMD SVM is susceptible to with our current placement of STGI vs
 TR loading."

>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p)
>>                             STACK_SIZE - PRIMARY_STACK_SIZE - IST_MAX * 
>> PAGE_SIZE);
>>  }
>>  
>> +bool memguard_is_stack_guard_page(unsigned long addr)
>> +{
>> +    addr &= STACK_SIZE - 1;
>> +
>> +    return addr >= IST_MAX * PAGE_SIZE &&
>> +           addr < STACK_SIZE - PRIMARY_STACK_SIZE;
>> +}
> 
> This probably would be better as a static inline, rather than a call
> into a separate translation unit, at which point a clever compiler might
> be able to split the loop in two (and may actually have an easier time
> doing so if the logic was expressed in terms of get_stack_page()).

I've consciously decided against an inline function here, because I
wanted the new function to live next to the existing ones, in order
to reduce the risk of someone not changing all three in lock step. I
don't think performance is a primary concern for AP bringup code.

As to using get_stack_page() - that would be an option, but to be
honest I prefer the current way of expressing things because it
better pairs with how the other two functions are written.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel