search for: rdtscp

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 rdtsc(p)?

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 rdtsc(p)?

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 >> during early boot. Move the rdtsc(p) #VC handler into common code and >> extend the #VC handlers. > > Do SEV-ES guests _always_ #VC on rdtsc(p)? Only if the hypervisor is intercepting those instructions. Thanks, Tom >

...0000 +0100 @@ -597,6 +597,11 @@ static int emulate_forced_invalid_op(str if ( !IS_PRIV(current->domain) ) clear_bit(X86_FEATURE_MTRR, &d); } + else if ( regs->eax == 0x80000001 ) + { + /* Modify Feature Information. */ + clear_bit(X86_FEATURE_RDTSCP % 32, &d); + } else { (void)cpuid_hypervisor_leaves(regs->eax, &a, &b, &c, &d); Index: 2007-01-16/xen/include/asm-x86/cpufeature.h =================================================================== --- 2007-01-16.orig/xen/include/asm-x86/cpufeature.h 20...

...for example with a particular guest OS that does > not necessary check CPUID for bits that are always present on Apple > hardware... But I bet that no one assumes that KVM paravirt MSRs are available even if the feature bit isn't set. Also, the one and only native feature flag I tested (rdtscp) actually does work: RDTSCP seems to send #UD if QEMU is passed -cpu host,-rdtscp. --Andy

...for example with a particular guest OS that does > not necessary check CPUID for bits that are always present on Apple > hardware... But I bet that no one assumes that KVM paravirt MSRs are available even if the feature bit isn't set. Also, the one and only native feature flag I tested (rdtscp) actually does work: RDTSCP seems to send #UD if QEMU is passed -cpu host,-rdtscp. --Andy

Hi Mike, On Fri, Apr 24, 2020 at 02:03:16PM -0700, Mike Stunes wrote: > I needed to allow RDTSC(P) from userspace and in early boot in order to > get userspace started properly. Patch below. Thanks, but this is not needed anymore. I removed the vc_context_filter from the code. The emulation code is now capable of safely handling any exception from user-space. Regards, Joerg

Hi Dave, On Fri, Apr 24, 2020 at 03:53:09PM -0700, Dave Hansen wrote: > Ahh, so any instruction that 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

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 -> #VC case. #VCs can

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 > to turn off IST before engaging in any funny business. Let me ponder > this a bit. Right, I dealt with that by

On Tue, Apr 28, 2020 at 09:55:12AM +0200, Joerg Roedel wrote: > On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: > > I have a somewhat serious question: should we use IST for #VC at all? > > As I understand it, Rome and Naples make it mandatory for hypervisors > > to intercept #DB, which means that, due to the MOV SS mess, it's sort > > of mandatory

On Tue, Jun 23, 2020 at 01:11:07PM +0200, Joerg Roedel wrote: > Hi Peter, > > On Tue, Jun 23, 2020 at 12:45:59PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2020 at 11:45:19AM +0200, Joerg Roedel wrote: > > > 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 >

On Tue, Jun 23, 2020 at 01:30:07PM +0200, Joerg Roedel wrote: > Note that this is an issue only with secure nested paging (SNP), which > is not enabled yet with this patch-set. When it gets enabled a stack > recursion check in the #VC handler is needed which panics the VM. That > also fixes the #VC-in-early-NMI problem. But you cannot do a recursion check in #VC, because the NMI can

On Tue, Jun 23, 2020 at 01:43:24PM +0200, Joerg Roedel wrote: > On Tue, Jun 23, 2020 at 01:14:43PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2020 at 01:11:07PM +0200, Joerg Roedel wrote: > > > > The v3 patchset implements an unconditional shift of the #VC IST entry > > > in the NMI handler, before it can trigger a #VC exception. > > > > Going by

On Tue, Jun 23, 2020 at 02:04:33PM +0200, Joerg Roedel wrote: > On Tue, Jun 23, 2020 at 01:48:18PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2020 at 01:30:07PM +0200, Joerg Roedel wrote: > > > But you cannot do a recursion check in #VC, because the NMI can happen > > on the first instruction of #VC, before we can increment our counter, > > and then the #VC can

On Tue, Jun 23, 2020 at 12:51:03PM +0100, Andrew Cooper wrote: > There are cases which are definitely non-recoverable. > > For both ES and SNP, a malicious hypervisor can mess with the guest > physmap to make the the NMI, #VC and #DF stacks all alias. > > For ES, this had better result in the #DF handler deciding that crashing > is the way out, whereas for SNP, this had

On Tue, Jun 23, 2020 at 02:12:37PM +0200, Joerg Roedel wrote: > On Tue, Jun 23, 2020 at 01:50:14PM +0200, Peter Zijlstra wrote: > > If SNP is the sole reason #VC needs to be IST, then I'd strongly urge > > you to only make it IST if/when you try and make SNP happen, not before. > > It is not the only reason, when ES guests gain debug register support > then #VC also

On Tue, Jun 23, 2020 at 03:40:03PM +0200, Joerg Roedel wrote: > On Tue, Jun 23, 2020 at 02:52:01PM +0200, Peter Zijlstra wrote: > > You only have that guarantee when any SNP #VC from kernel is an > > automatic panic. But in that case, what's the point of having the > > recursion count? > > It is not a recursion count, it is a stack-recursion check. Basically >

On Tue, Jun 23, 2020 at 04:53:44PM +0200, Peter Zijlstra wrote: > +noinstr void idtentry_validate_ist(struct pt_regs *regs) > +{ > + if ((regs->sp & ~(EXCEPTION_STKSZ-1)) == > + (_RET_IP_ & ~(EXCEPTION_STKSZ-1))) > + die("IST stack recursion", regs, 0); > +} Yes, this is a start, it doesn't cover the case where the NMI stack is in-between, so I

On Tue, Jun 23, 2020 at 04:49:40PM +0200, Joerg Roedel wrote: > > We're talking about the 3rd case where the only reason things 'work' is > > because we'll have to panic(): > > > > - #MC > > Okay, #MC is special and can only be handled on a best-effort basis, as > #MC could happen anytime, also while already executing the #MC handler. I think