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

Re: [Xen-devel] [PATCH v4 08/10] x86: Enable Supervisor Mode Access Prevention (SMAP) for Xen



>>> On 06.05.14 at 07:19, <feng.wu@xxxxxxxxx> wrote:

> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Monday, May 05, 2014 7:20 PM
>> To: Wu, Feng
>> Cc: andrew.cooper3@xxxxxxxxxx; ian.campbell@xxxxxxxxxx; Dong, Eddie;
>> Nakajima, Jun; Tian, Kevin; xen-devel@xxxxxxxxxxxxx 
>> Subject: Re: [PATCH v4 08/10] x86: Enable Supervisor Mode Access Prevention
>> (SMAP) for Xen
>> 
>> >>> On 05.05.14 at 10:23, <feng.wu@xxxxxxxxx> wrote:
>> > @@ -1394,6 +1401,13 @@ void __init noreturn __start_xen(unsigned long
>> mbi_p)
>> >                          bootstrap_map, cmdline) != 0)
>> >          panic("Could not set up DOM0 guest OS");
>> >
>> > +    /*
>> > +     * Enable SMAP after constructing domain0, since there are lots of
>> accesses to
>> > +     * user pages in construct_dom0(), which is safe at the current stage.
>> > +     */
>> > +    if ( cpu_has_smap )
>> > +        set_in_cr4(X86_CR4_SMAP);
>> > +
>> 
>> I should have noticed this on the previous round already - the way
>> it's being done right now will leave APs with SMAP disabled for an
>> indeterminate amount of time (until they first reload CR4 from
>> mmu_cr4_features).
> 
> Yes, that's a question. In that case, we should move this part to the place 
> where
> it was. So we should come back to the question about how to handle 
> stac()/clac()
> in construct_dom0(), right?

An option might be to move it back to where it was, but clear the flag
temporarily on the one CPU calling construct_dom0(). That's a little
hackish, but properly commented acceptable imo.

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®.