search for: do_vmm_communication

...hat can have an instruction intercept set potentially needs to be able to tolerate a #VC? Those instruction intercepts are under the control of the (untrusted relative to the guest) hypervisor, right? >From the main sev-es series: +#ifdef CONFIG_AMD_MEM_ENCRYPT +idtentry vmm_communication do_vmm_communication has_error_code=1 +#endif Since this is set as non-paranoid, that both limits the instructions that can be used in entry paths *and* limits the future architecture from being able add instructions that a current SEV-ES guest doesn't know about. Does SEV-ES have versioning so guests can tell...

...hat can have an instruction intercept set potentially needs to be able to tolerate a #VC? Those instruction intercepts are under the control of the (untrusted relative to the guest) hypervisor, right? >From the main sev-es series: +#ifdef CONFIG_AMD_MEM_ENCRYPT +idtentry vmm_communication do_vmm_communication has_error_code=1 +#endif Since this is set as non-paranoid, that both limits the instructions that can be used in entry paths *and* limits the future architecture from being able add instructions that a current SEV-ES guest doesn't know about. Does SEV-ES have versioning so guests can tell...

....c | 32 +++++++++++++++++++++++--------- 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c index f5bff4219f6f..d128a9397639 100644 --- a/arch/x86/kernel/sev-es.c +++ b/arch/x86/kernel/sev-es.c @@ -254,16 +254,16 @@ dotraplinkage void do_vmm_communication(struct pt_regs *regs, unsigned long exit finish_insn(&ctxt); break; case ES_UNSUPPORTED: - pr_emerg("Unsupported exit-code 0x%02lx in early #VC exception (IP: 0x%lx)\n", - exit_code, regs->ip); + pr_err_ratelimited("Unsupported exit-code 0x%02lx in early #VC excep...

...e GHCB needs to be backed up, so that it doesn't > destroy the GHCB contents of the first #VC handling path. Isn't it possible for the #VC handler to hit a #PF, e.g. on copy_from_user() in insn_fetch_from_user()? If that happens, what prevents the #PF handler from hitting a #VC? AIUI, do_vmm_communication() panics if the backup GHCB is already in use, e.g. #VC->#PF->#VC->NMI->#VC would be fatal.

...100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/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 1049...

...t > potentially needs to be able to tolerate a #VC? Those instruction > intercepts are under the control of the (untrusted relative to the > guest) hypervisor, right? > > >From the main sev-es series: > > +#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....

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 > during early boot. Move the rdtsc(p) #VC handler into common code and > extend the #VC handlers. Do SEV-ES guests _always_ #VC on

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 > during early boot. Move the rdtsc(p) #VC handler into common code and > extend the #VC handlers. Do SEV-ES guests _always_ #VC on

...le to tolerate a #VC? Those instruction > > intercepts are under the control of the (untrusted relative to the > > guest) hypervisor, right? > > > > >From the main sev-es series: > > > > +#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 allo...

...le to tolerate a #VC? Those instruction > > intercepts are under the control of the (untrusted relative to the > > guest) hypervisor, right? > > > > >From the main sev-es series: > > > > +#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 allo...

On Tue, Apr 28, 2020 at 05:16:57PM +0200, Joerg Roedel wrote: > diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c > index a4fa7f351bf2..bc3a58427028 100644 > --- a/arch/x86/kernel/sev-es.c > +++ b/arch/x86/kernel/sev-es.c > @@ -10,6 +10,7 @@ > #include <linux/sched/debug.h> /* For show_regs() */ > #include <linux/percpu-defs.h> > #include

On Tue, Apr 28, 2020 at 05:16:57PM +0200, Joerg Roedel wrote: > diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c > index a4fa7f351bf2..bc3a58427028 100644 > --- a/arch/x86/kernel/sev-es.c > +++ b/arch/x86/kernel/sev-es.c > @@ -10,6 +10,7 @@ > #include <linux/sched/debug.h> /* For show_regs() */ > #include <linux/percpu-defs.h> > #include

Hi, here is the first public post of the patch-set to enable Linux to run under SEV-ES enabled hypervisors. The code is mostly feature-complete, but there are still a couple of bugs to fix. Nevertheless, given the size of the patch-set, I think it is about time to ask for initial feedback of the changes that come with it. To better understand the code here is a quick explanation of SEV-ES first.

Hi, here is the first public post of the patch-set to enable Linux to run under SEV-ES enabled hypervisors. The code is mostly feature-complete, but there are still a couple of bugs to fix. Nevertheless, given the size of the patch-set, I think it is about time to ask for initial feedback of the changes that come with it. To better understand the code here is a quick explanation of SEV-ES first.

Hi, here is the next version of changes to enable Linux to run as an SEV-ES guest. The code was rebased to v5.7-rc3 and got a fair number of changes since the last version. What is SEV-ES ============== SEV-ES is an acronym for 'Secure Encrypted Virtualization - Encrypted State' and means a hardware feature of AMD processors which hides the register state of VCPUs to the hypervisor by

Hi, here is the next version of changes to enable Linux to run as an SEV-ES guest. The code was rebased to v5.7-rc3 and got a fair number of changes since the last version. What is SEV-ES ============== SEV-ES is an acronym for 'Secure Encrypted Virtualization - Encrypted State' and means a hardware feature of AMD processors which hides the register state of VCPUs to the hypervisor by