Re: [Xen-devel] [PATCH v3 5/9] x86: Temporary disable SMAP to legally access user pages in kernel mode

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.05.14 at 09:25, <feng.wu@xxxxxxxxx> wrote:

> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Monday, May 05, 2014 2:57 PM
>> To: Wu, Feng
>> Cc: andrew.cooper3@xxxxxxxxxx; ian.campbell@xxxxxxxxxx; Dong, Eddie;
>> Nakajima, Jun; Tian, Kevin; xen-devel@xxxxxxxxxxxxx 
>> Subject: RE: [PATCH v3 5/9] x86: Temporary disable SMAP to legally access 
> user
>> pages in kernel mode
>> 
>> >>> On 05.05.14 at 07:12, <feng.wu@xxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> >>> On 28.04.14 at 05:16, <feng.wu@xxxxxxxxx> wrote:
>> >> > --- a/xen/arch/x86/x86_64/compat/entry.S
>> >> > +++ b/xen/arch/x86/x86_64/compat/entry.S
>> >> > @@ -266,6 +266,7 @@ ENTRY(compat_int80_direct_trap)
>> >> >  /* On return only %rbx and %rdx are guaranteed non-clobbered.
>> >> */
>> >> >  compat_create_bounce_frame:
>> >> >          ASSERT_INTERRUPTS_ENABLED
>> >> > +        ASM_STAC
>> >> >          mov   %fs,%edi
>> >> >          testb $2,UREGS_cs+8(%rsp)
>> >> >          jz    1f
>> >>
>> >> I think this should be deferred as much as possible; I even think it is
>> >> warranted to put this at two places here (in the two conditional
>> >> execution branches) just to avoid doing this too early.
>> >
>> > I think about this again. Seems ASM_STAC/ASM_CLAC is not needed for
>> > compat_create_bounce_frame, since in this chunk of code, it only accesses
>> > the pv guest's kernel stack, which should be in ring 1 for 32-bit pv. Is my
>> > understanding correct? Thanks a lot!
>> 
>> This is indeed correct, but at the same time means that we need to
>> be aware that SMAP doesn't shield us at all from 32-bit PV guests, i.e.
>> is only of limited use.
> 
> I am not quite understand about this, why eliminating ASM_STAC/ASM_CAL here
> results in " SMAP doesn't shield us at all from 32-bit PV guests "? Thanks a 
> lot!

I didn't say that; what I said was that there is no shielding (i.e.
irrespective of the absence/presence of CLAC in this code path).

Jan


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