From: Joerg Roedel <joro@8bytes.org> To: Peter Zijlstra <peterz@infradead.org> Cc: x86@kernel.org, Joerg Roedel <jroedel@suse.de>, hpa@zytor.com, Andy Lutomirski <luto@kernel.org>, Dave Hansen <dave.hansen@linux.intel.com>, Jiri Slaby <jslaby@suse.cz>, Dan Williams <dan.j.williams@intel.com>, Tom Lendacky <thomas.lendacky@amd.com>, Juergen Gross <jgross@suse.com>, Kees Cook <keescook@chromium.org>, David Rientjes <rientjes@google.com>, Cfir Cohen <cfir@google.com>, Erdem Aktas <erdemaktas@google.com>, Masami Hiramatsu <mhiramat@kernel.org>, Mike Stunes <mstunes@vmware.com>, Sean Christopherson <seanjc@google.com>, Martin Radev <martin.b.radev@gmail.com>, Arvind Sankar <nivedita@alum.mit.edu>, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH v4 3/6] x86/sev-es: Split up runtime #VC handler for correct state tracking Date: Thu, 10 Jun 2021 13:30:27 +0200 [thread overview] Message-ID: <YMH30/wFyE1JkKZg@8bytes.org> (raw) In-Reply-To: <YMHnP1qgvznyYazv@hirez.programming.kicks-ass.net> Hi Peter, On Thu, Jun 10, 2021 at 12:19:43PM +0200, Peter Zijlstra wrote: > On Thu, Jun 10, 2021 at 11:11:38AM +0200, Joerg Roedel wrote: > > > +static void vc_handle_from_kernel(struct pt_regs *regs, unsigned long error_code) > > static noinstr ... Right, I forgot that, will update the patch and add the correct noinstr annotations. > > + if (user_mode(regs)) > > + vc_handle_from_user(regs, error_code); > > + else > > + vc_handle_from_kernel(regs, error_code); > > } > > #DB and MCE use idtentry_mce_db and split out in asm. When I look at > idtentry_vc, it appears to me that VC_SAFE_STACK already implies > from-user, or am I reading that wrong? VC_SAFE_STACK does not imply from-user. It means that the #VC handler asm code was able to switch away from the IST stack to either the task-stack (if from-user or syscall gap) or to the previous kernel stack. There is a check in vc_switch_off_ist() that shows which stacks are considered safe. If it can not switch to a safe stack the VC entry code switches to the fall-back stack and a special handler function is called, which for now just panics the system. > How about you don't do that and have exc_ call your new from_kernel > function, then we know that safe_stack_ is always from-user. Then also > maybe do: > > s/VS_SAFE_STACK/VC_USER/ > s/safe_stack_/noist_/ > > to match all the others (#DB/MCE). So #VC is different from #DB and #MCE in that it switches stacks even when coming from kernel mode, so that the #VC handler can be nested. What I can do is to call the from_user function directly from asm in the .Lfrom_user_mode_switch_stack path. That will avoid having another from_user check in C code. > DEFINE_IDTENTRY_VC(exc_vc) > { > if (unlikely(on_vc_fallback_stack(regs))) { > instrumentation_begin(); > panic("boohooo\n"); > instrumentation_end(); The on_vc_fallback_stack() path is for now only calling panic(), because it can't be hit when the hypervisor is behaving correctly. In the future it is not clear yet if that path needs to be extended for SNP page validation exceptions, which can basically happen anywhere. The implementation of SNP should make sure that all memory touched during entry (while on unsafe stacks) is always validated, but not sure yet if that holds when live-migration of SNP guests is added to the picture. There is the possibility that this doesn't fit in the above branch, but it can also be moved to a separate function if needed. > } > > vc_from_kernel(); > } > > DEFINE_IDTENTRY_VC_USER(exc_vc) > { > vc_from_user(); > } > > Which is, I'm thinking, much simpler, no? Okay, I am going to try this out. Thanks for your feedback. Regards, Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org> To: Peter Zijlstra <peterz@infradead.org> Cc: kvm@vger.kernel.org, Dave Hansen <dave.hansen@linux.intel.com>, virtualization@lists.linux-foundation.org, Arvind Sankar <nivedita@alum.mit.edu>, hpa@zytor.com, Jiri Slaby <jslaby@suse.cz>, x86@kernel.org, David Rientjes <rientjes@google.com>, Martin Radev <martin.b.radev@gmail.com>, Tom Lendacky <thomas.lendacky@amd.com>, Joerg Roedel <jroedel@suse.de>, Kees Cook <keescook@chromium.org>, Cfir Cohen <cfir@google.com>, linux-coco@lists.linux.dev, Andy Lutomirski <luto@kernel.org>, Dan Williams <dan.j.williams@intel.com>, Juergen Gross <jgross@suse.com>, Mike Stunes <mstunes@vmware.com>, Sean Christopherson <seanjc@google.com>, linux-kernel@vger.kernel.org, Masami Hiramatsu <mhiramat@kernel.org>, Erdem Aktas <erdemaktas@google.com> Subject: Re: [PATCH v4 3/6] x86/sev-es: Split up runtime #VC handler for correct state tracking Date: Thu, 10 Jun 2021 13:30:27 +0200 [thread overview] Message-ID: <YMH30/wFyE1JkKZg@8bytes.org> (raw) In-Reply-To: <YMHnP1qgvznyYazv@hirez.programming.kicks-ass.net> Hi Peter, On Thu, Jun 10, 2021 at 12:19:43PM +0200, Peter Zijlstra wrote: > On Thu, Jun 10, 2021 at 11:11:38AM +0200, Joerg Roedel wrote: > > > +static void vc_handle_from_kernel(struct pt_regs *regs, unsigned long error_code) > > static noinstr ... Right, I forgot that, will update the patch and add the correct noinstr annotations. > > + if (user_mode(regs)) > > + vc_handle_from_user(regs, error_code); > > + else > > + vc_handle_from_kernel(regs, error_code); > > } > > #DB and MCE use idtentry_mce_db and split out in asm. When I look at > idtentry_vc, it appears to me that VC_SAFE_STACK already implies > from-user, or am I reading that wrong? VC_SAFE_STACK does not imply from-user. It means that the #VC handler asm code was able to switch away from the IST stack to either the task-stack (if from-user or syscall gap) or to the previous kernel stack. There is a check in vc_switch_off_ist() that shows which stacks are considered safe. If it can not switch to a safe stack the VC entry code switches to the fall-back stack and a special handler function is called, which for now just panics the system. > How about you don't do that and have exc_ call your new from_kernel > function, then we know that safe_stack_ is always from-user. Then also > maybe do: > > s/VS_SAFE_STACK/VC_USER/ > s/safe_stack_/noist_/ > > to match all the others (#DB/MCE). So #VC is different from #DB and #MCE in that it switches stacks even when coming from kernel mode, so that the #VC handler can be nested. What I can do is to call the from_user function directly from asm in the .Lfrom_user_mode_switch_stack path. That will avoid having another from_user check in C code. > DEFINE_IDTENTRY_VC(exc_vc) > { > if (unlikely(on_vc_fallback_stack(regs))) { > instrumentation_begin(); > panic("boohooo\n"); > instrumentation_end(); The on_vc_fallback_stack() path is for now only calling panic(), because it can't be hit when the hypervisor is behaving correctly. In the future it is not clear yet if that path needs to be extended for SNP page validation exceptions, which can basically happen anywhere. The implementation of SNP should make sure that all memory touched during entry (while on unsafe stacks) is always validated, but not sure yet if that holds when live-migration of SNP guests is added to the picture. There is the possibility that this doesn't fit in the above branch, but it can also be moved to a separate function if needed. > } > > vc_from_kernel(); > } > > DEFINE_IDTENTRY_VC_USER(exc_vc) > { > vc_from_user(); > } > > Which is, I'm thinking, much simpler, no? Okay, I am going to try this out. Thanks for your feedback. Regards, Joerg _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-06-10 11:30 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-10 9:11 [PATCH v4 0/6] x86/sev-es: Fixes for SEV-ES Guest Support Joerg Roedel 2021-06-10 9:11 ` Joerg Roedel 2021-06-10 9:11 ` [PATCH v4 1/6] x86/sev-es: Fix error message in runtime #VC handler Joerg Roedel 2021-06-10 9:11 ` Joerg Roedel 2021-06-10 9:11 ` [PATCH v4 2/6] x86/sev-es: Disable IRQs while GHCB is active Joerg Roedel 2021-06-10 9:11 ` Joerg Roedel 2021-06-11 14:05 ` Borislav Petkov 2021-06-11 14:05 ` Borislav Petkov 2021-06-11 14:20 ` Joerg Roedel 2021-06-11 14:20 ` Joerg Roedel 2021-06-11 14:34 ` Borislav Petkov 2021-06-11 14:34 ` Borislav Petkov 2021-06-10 9:11 ` [PATCH v4 3/6] x86/sev-es: Split up runtime #VC handler for correct state tracking Joerg Roedel 2021-06-10 9:11 ` Joerg Roedel 2021-06-10 10:19 ` Peter Zijlstra 2021-06-10 10:19 ` Peter Zijlstra 2021-06-10 11:30 ` Joerg Roedel [this message] 2021-06-10 11:30 ` Joerg Roedel 2021-06-10 9:11 ` [PATCH v4 4/6] x86/insn-eval: Make 0 a valid RIP for insn_get_effective_ip() Joerg Roedel 2021-06-10 9:11 ` Joerg Roedel 2021-06-10 9:11 ` [PATCH v4 5/6] x86/insn: Extend error reporting from insn_fetch_from_user[_inatomic]() Joerg Roedel 2021-06-10 9:11 ` Joerg Roedel 2021-06-10 9:11 ` [PATCH v4 6/6] x86/sev-es: Propagate #GP if getting linear instruction address failed Joerg Roedel 2021-06-10 9:11 ` Joerg Roedel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YMH30/wFyE1JkKZg@8bytes.org \ --to=joro@8bytes.org \ --cc=cfir@google.com \ --cc=dan.j.williams@intel.com \ --cc=dave.hansen@linux.intel.com \ --cc=erdemaktas@google.com \ --cc=hpa@zytor.com \ --cc=jgross@suse.com \ --cc=jroedel@suse.de \ --cc=jslaby@suse.cz \ --cc=keescook@chromium.org \ --cc=kvm@vger.kernel.org \ --cc=linux-coco@lists.linux.dev \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=martin.b.radev@gmail.com \ --cc=mhiramat@kernel.org \ --cc=mstunes@vmware.com \ --cc=nivedita@alum.mit.edu \ --cc=peterz@infradead.org \ --cc=rientjes@google.com \ --cc=seanjc@google.com \ --cc=thomas.lendacky@amd.com \ --cc=virtualization@lists.linux-foundation.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.