archive mirror
 help / color / mirror / Atom feed
From: Joerg Roedel <>
To: Peter Zijlstra <>
Cc:, Joerg Roedel <>,, Andy Lutomirski <>,
	Dave Hansen <>,
	Jiri Slaby <>,
	Dan Williams <>,
	Tom Lendacky <>,
	Juergen Gross <>,
	Kees Cook <>,
	David Rientjes <>,
	Cfir Cohen <>, Erdem Aktas <>,
	Masami Hiramatsu <>,
	Mike Stunes <>,
	Sean Christopherson <>,
	Martin Radev <>,
	Arvind Sankar <>,,,,
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/> (raw)
In-Reply-To: <>

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

> > +	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/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.

> {
> 	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

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();
> }
> {
> 	vc_from_user();
> }
> Which is, I'm thinking, much simpler, no?

Okay, I am going to try this out. Thanks for your feedback.



  reply	other threads:[~2021-06-10 11:30 UTC|newest]

Thread overview: 12+ 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 ` [PATCH v4 1/6] x86/sev-es: Fix error message in runtime #VC handler Joerg Roedel
2021-06-10  9:11 ` [PATCH v4 2/6] x86/sev-es: Disable IRQs while GHCB is active Joerg Roedel
2021-06-11 14:05   ` Borislav Petkov
2021-06-11 14:20     ` Joerg Roedel
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 10:19   ` Peter Zijlstra
2021-06-10 11:30     ` Joerg Roedel [this message]
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 ` [PATCH v4 5/6] x86/insn: Extend error reporting from insn_fetch_from_user[_inatomic]() Joerg Roedel
2021-06-10  9:11 ` [PATCH v4 6/6] x86/sev-es: Propagate #GP if getting linear instruction address failed 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YMH30/ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).