[MODERATED] Re: [PATCH v5 6/8] NX 6

On Tue, Jul 02, 2019 at 11:21:14PM +0200, speck for Thomas Gleixner wrote:
> On Tue, 2 Jul 2019, speck for Dave Hansen wrote:
> > On 7/2/19 1:46 PM, speck for Thomas Gleixner wrote:
> > >>  static ssize_t itlb_multihit_show_state(char *buf)
> > >>  {
> > >>  	return sprintf(buf, "Processor vulnerable\n");
> > > So this is the default state when KVM_INTEL = n. But if KVM is not in use
> > > is this actually an issue?
> > 
> > IMNHO, there's a very low chance of malicious exploitation without KVM.
> > 
> > There were some ancient huge page errata (details in
> > __split_huge_pmd_locked()) that required us to go through a
> > Present->Not-Present->Present(new size) dance when splitting THPs.  That
> > dance is also an effective mitigation against someone causing lots of
> > huge page splits/joins as a trigger for tlb-multihit.  That covers
> > userspace mappings that might be affected.
> > 
> > The other concern would be for exposure from changes to the kernel's
> > text mappings.  Those probably don't ever happen in response to
> > unprivileged operations.  Folks at Intel were asked to do an audit to
> > make sure that none of them are exposed.  Maybe Mark can share the
> > results of the audit.
>  
> So whatever the result is the mitigation show output needs to be:
> 
> #ifdef KVM_INTEL
> show_bug()
> {
> 	if (kvm_mitigated)
> 		print("Host: ??? KVM: Mitigated\n");
> 	else
> 		print("Host: ??? KVM: Vulnerable\n");
> }
> #else
> show_bug()
> {
> 	print("Host ???\n");
> }
> #endif

Due to previous errata kernel already follows the protocol to avoid this
issue on the host. Host mitigation state can be "Not vulnerable".

Thanks,
Pawan