search for: shift_ist

...T > > +idtentry vmm_communication do_vmm_communication has_error_code=1 > > +#endif > > The next version of the patch-set (which I will hopefully have ready > next week) will have this changed. The #VC exception handler uses an IST > stack and is set to paranoid=1 and shift_ist. The IST stacks for the #VC > handler are only allocated when SEV-ES is active. shift_ist is gross. What's it for? If it's not needed, I'd rather not use it, and I eventually want to get rid of it for #DB as well. --Andy

...T > > +idtentry vmm_communication do_vmm_communication has_error_code=1 > > +#endif > > The next version of the patch-set (which I will hopefully have ready > next week) will have this changed. The #VC exception handler uses an IST > stack and is set to paranoid=1 and shift_ist. The IST stacks for the #VC > handler are only allocated when SEV-ES is active. shift_ist is gross. What's it for? If it's not needed, I'd rather not use it, and I eventually want to get rid of it for #DB as well. --Andy

On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: > shift_ist is gross. What's it for? If it's not needed, I'd rather > not use it, and I eventually want to get rid of it for #DB as well. The #VC handler needs to be able to nest, there is no way around that for various reasons, the two most important ones are: 1. The #VC -> NMI -> #V...

> On Apr 25, 2020, at 12:10 PM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: >> shift_ist is gross. What's it for? If it's not needed, I'd rather >> not use it, and I eventually want to get rid of it for #DB as well. > > The #VC handler needs to be able to nest, there is no way around that > for various reasons, the two most important ones are: > >...

> On Apr 25, 2020, at 12:10 PM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: >> shift_ist is gross. What's it for? If it's not needed, I'd rather >> not use it, and I eventually want to get rid of it for #DB as well. > > The #VC handler needs to be able to nest, there is no way around that > for various reasons, the two most important ones are: > >...

On 4/24/20 2:27 PM, Tom Lendacky wrote: > On 4/24/20 4:24 PM, Dave Hansen wrote: >> On 4/24/20 2:03 PM, Mike Stunes wrote: >>> I needed to allow RDTSC(P) from userspace and in early boot in order to >>> get userspace started properly. Patch below. >>> >>> --- >>> SEV-ES guests will need to execute rdtsc and rdtscp from userspace and

On 4/24/20 2:27 PM, Tom Lendacky wrote: > On 4/24/20 4:24 PM, Dave Hansen wrote: >> On 4/24/20 2:03 PM, Mike Stunes wrote: >>> I needed to allow RDTSC(P) from userspace and in early boot in order to >>> get userspace started properly. Patch below. >>> >>> --- >>> SEV-ES guests will need to execute rdtsc and rdtscp from userspace and

...fe_callback) ENCODE_FRAME_POINTER jmp error_exit END(xen_failsafe_callback) +#endif /* CONFIG_XEN_PV */ +#ifdef CONFIG_XEN apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \ xen_hvm_callback_vector xen_evtchn_do_upcall @@ -998,7 +1000,7 @@ idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK idtentry stack_segment do_stack_segment has_error_code=1 -#ifdef CONFIG_XEN +#ifdef CONFIG_XEN_PV idtentry xen_debug do_debug has_error_code=0 idtentry xen_int3 do_int3 has_error_code=0 idtentry xen...

...the return RSP and RIP. It needs to take into account the case when PT_REGS is not fully populated on the return side. Alternativly the NMI handler could safe/restore the contents of the #VC IST stack or just switch to a special #VC-in-NMI IST stack. All in all it could get complicated, and imho shift_ist would have been simpler, but who am I anyway... Or maybe you have a better idea how to implement this, so I'd like to hear your opinion first before I spend too many days implementing something. Regards, Joerg

...+#ifdef CONFIG_AMD_MEM_ENCRYPT > +idtentry vmm_communication do_vmm_communication has_error_code=1 > +#endif The next version of the patch-set (which I will hopefully have ready next week) will have this changed. The #VC exception handler uses an IST stack and is set to paranoid=1 and shift_ist. The IST stacks for the #VC handler are only allocated when SEV-ES is active. > That's a fun point because it means that the (untrusted) hypervisor can > cause endless faults. I *guess* we have mitigation for this with our > stack guard pages, but it's still a bit nasty that the...

...eds to take into account the case when PT_REGS is not > fully populated on the return side. > > Alternativly the NMI handler could safe/restore the contents of the #VC > IST stack or just switch to a special #VC-in-NMI IST stack. > > All in all it could get complicated, and imho shift_ist would have been > simpler, but who am I anyway... > > Or maybe you have a better idea how to implement this, so I'd like to > hear your opinion first before I spend too many days implementing > something. OK, excuse my ignorance, but I'm not seeing how that IST shifting non...

...ering { #define CEA_ESTACK_PAGES \ (sizeof(struct cea_exception_stacks) / PAGE_SIZE) +/* + * VC Handler IST Stacks + * + * The IST stacks for the #VC handler are only allocated when SEV-ES is active, + * so they are not part of 'struct exception_stacks'. + * + * The VC handler uses shift_ist so that #VC can be nested. Nesting happens for + * example when the #VC handler has to call printk in the case of and error or + * when emulating 'movs' instructions. + * + * NMIs are another special case which can cause nesting of #VC handlers. The + * do_nmi() code path can cause #VC, e.g...

...h/x86/entry/entry_64.S @@ -1210,6 +1210,10 @@ idtentry async_page_fault do_async_page_fault has_error_code=1 read_cr2=1 idtentry machine_check do_mce has_error_code=0 paranoid=1 #endif +#ifdef CONFIG_AMD_MEM_ENCRYPT +idtentry vmm_communication do_vmm_communication has_error_code=1 paranoid=1 shift_ist=IST_INDEX_VC ist_offset=VC_STACK_OFFSET +#endif + /* * Save all registers in pt_regs, and switch gs if needed. * Use slow, but surefire "are we in kernel?" check. diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h index 104991c05425..37f6e86ac53a 100644 --- a/ar...

On Sat, Apr 25, 2020 at 1:23 PM Joerg Roedel <joro at 8bytes.org> wrote: > > On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote: > > I assume the race you mean is: > > > > #VC > > Immediate NMI before IST gets shifted > > #VC > > > > Kaboom. > > > > How are you dealing with this? Ultimately, I think that NMI will need

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to