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

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

> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> Sent: Wednesday, March 9, 2016 6:46 PM
> To: Wu, Feng <feng.wu@xxxxxxxxx>; Jan Beulich <JBeulich@xxxxxxxx>; xen-
> devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Cc: Keir Fraser <keir@xxxxxxx>
> Subject: Re: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV
> guest code
> 
> On 09/03/16 08:09, Wu, Feng wrote:
> 
> >> --- a/xen/arch/x86/x86_64/entry.S
> >> +++ b/xen/arch/x86/x86_64/entry.S
> >> @@ -434,6 +434,7 @@ ENTRY(dom_crash_sync_extable)
> >>
> >>  ENTRY(common_interrupt)
> >>          SAVE_ALL CLAC
> >> +        SMEP_SMAP_RESTORE
> >>          movq %rsp,%rdi
> >>          callq do_IRQ
> >>          jmp ret_from_intr
> >> @@ -454,13 +455,64 @@ ENTRY(page_fault)
> >>  GLOBAL(handle_exception)
> >>          SAVE_ALL CLAC
> >>  handle_exception_saved:
> >> +        GET_CURRENT(%rbx)
> >>          testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
> >>          jz    exception_with_ints_disabled
> >> -        sti
> >> +
> >> +.Lsmep_smap_orig:
> >> +        jmp   0f
> >> +        .if 0 // GAS bug (affecting at least 2.22 ... 2.26)
> >> +        .org .Lsmep_smap_orig + (.Lsmep_smap_alt_end - .Lsmep_smap_alt),
> 0xcc
> >> +        .else
> >> +        // worst case: rex + opcode + modrm + 4-byte displacement
> >> +        .skip (1 + 1 + 1 + 4) - 2, 0xcc
> >> +        .endif
> >> +        .pushsection .altinstr_replacement, "ax"
> >> +.Lsmep_smap_alt:
> >> +        mov   VCPU_domain(%rbx),%rax
> >> +.Lsmep_smap_alt_end:
> >> +        .section .altinstructions, "a"
> >> +        altinstruction_entry .Lsmep_smap_orig, .Lsmep_smap_alt, \
> >> +                             X86_FEATURE_SMEP, \
> >> +                             (.Lsmep_smap_alt_end - .Lsmep_smap_alt), \
> >> +                             (.Lsmep_smap_alt_end - .Lsmep_smap_alt)
> >> +        altinstruction_entry .Lsmep_smap_orig, .Lsmep_smap_alt, \
> >> +                             X86_FEATURE_SMAP, \
> >> +                             (.Lsmep_smap_alt_end - .Lsmep_smap_alt), \
> >> +                             (.Lsmep_smap_alt_end - .Lsmep_smap_alt)
> >> +        .popsection
> >> +
> >> +        testb $3,UREGS_cs(%rsp)
> >> +        jz    0f
> >> +        cmpb  $0,DOMAIN_is_32bit_pv(%rax)
> >> +        je    0f
> >> +        call  cr4_smep_smap_restore
> >> +        /*
> >> +         * An NMI or #MC may occur between clearing CR4.SMEP and
> CR4.SMAP in
> > Do you mean "before" when you typed "between" above?
> 
> The meaning is "between (clearing CR4.SMEP and CR4.SMAP in
> compat_restore_all_guest) and (it actually returning to guest)"
> 
> Nested lists in English are a source of confusion, even to native speakers.

Oh, thanks for the clarification! Do you know how "An NMI or #MC may occur
between clearing CR4.SMEP and CR4.SMAP in compat_restore_all_guest and
it actually returning to guest context, in which case the guest would run with
the two features enabled. " can happen? Especially how the guest can run
with the two features enabled? 

Thanks,
Feng

> 
> ~Andrew
> 
> >> +         * compat_restore_all_guest and it actually returning to guest
> >> +         * context, in which case the guest would run with the two 
> >> features
> >> +         * enabled. The only bad that can happen from this is a kernel 
> >> mode
> >> +         * #PF which the guest doesn't expect. Rather than trying to make 
> >> the
> >> +         * NMI/#MC exit path honor the intended CR4 setting, simply check
> >> +         * whether the wrong CR4 was in use when the #PF occurred, and 
> >> exit
> >> +         * back to the guest (which will in turn clear the two CR4 bits) 
> >> to
> >> +         * re-execute the instruction. If we get back here, the CR4 bits
> >> +         * should then be found clear (unless another NMI/#MC occurred at
> >> +         * exactly the right time), and we'll continue processing the
> >> +         * exception as normal.
> >> +         */
> 


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