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

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----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?


> 
> > --- a/xen/arch/x86/traps.c
> > +++ b/xen/arch/x86/traps.c
> > @@ -1182,11 +1182,12 @@ static int handle_gdt_ldt_mapping_fault(
> >  enum pf_type {
> >      real_fault,
> >      smep_fault,
> > +    smap_fault,
> >      spurious_fault
> >  };
> >
> >  static enum pf_type __page_fault_type(
> > -    unsigned long addr, unsigned int error_code)
> > +    unsigned long addr, const struct cpu_user_regs *regs)
> 
> I see you followed the constification request here.
> 
> >  static enum pf_type spurious_page_fault(
> > -    unsigned long addr, unsigned int error_code)
> > +    unsigned long addr, struct cpu_user_regs *regs)
> 
> But why not here?
> 
> Jan

Thanks,
Feng

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