[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |