[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV guest code



>>> On 09.03.16 at 09:09, <feng.wu@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Friday, March 4, 2016 7:28 PM
>> @@ -1471,7 +1475,10 @@ void __init noreturn __start_xen(unsigne
>>       * copy_from_user().
>>       */
>>      if ( cpu_has_smap )
>> +    {
>> +        cr4_smep_smap_mask &= ~X86_CR4_SMAP;
> 
> You change ' cr4_smep_smap_mask ' here ...
> 
>>          write_cr4(read_cr4() & ~X86_CR4_SMAP);
>> +    }
>> 
>>      printk("%sNX (Execute Disable) protection %sactive\n",
>>             cpu_has_nx ? XENLOG_INFO : XENLOG_WARNING "Warning: ",
>> @@ -1488,7 +1495,10 @@ void __init noreturn __start_xen(unsigne
>>          panic("Could not set up DOM0 guest OS");
>> 
>>      if ( cpu_has_smap )
>> +    {
>>          write_cr4(read_cr4() | X86_CR4_SMAP);
>> +        cr4_smep_smap_mask |= X86_CR4_SMAP;
> 
> ... and here. I am wonder whether it is because Domain 0 can actually start
> running between the two place? Or I don't think the changes in the above
> two places is needed. right?

They very definitely needed, to avoid hitting the BUG in
cr4_pv32_restore (cr4_smep_smap_restore in this patch
version) in every interrupt that occurs while Dom0 is being
constructed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.