[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [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. ~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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |