From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <ak@linux.intel.com>
Received: from mga03.intel.com ([134.134.136.65])
	by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
	(Exim 4.80)
	(envelope-from <ak@linux.intel.com>)
	id 1fB0Sf-0006Pe-8A
	for speck@linutronix.de; Tue, 24 Apr 2018 18:06:34 +0200
Date: Tue, 24 Apr 2018 09:06:17 -0700
From: Andi Kleen <ak@linux.intel.com>
Subject: [MODERATED] Re: L1D-Fault KVM mitigation
Message-ID: <20180424160617.GC14273@tassilo.jf.intel.com>
References: <20180424090630.wlghmrpasn7v7wbn@suse.de>
 <20180424093537.GC4064@hirez.programming.kicks-ass.net>
 <20180424103037.2lwafyzyoxbinapv@suse.de>
 <alpine.DEB.2.21.1804241256220.1679@nanos.tec.linutronix.de>
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.1804241256220.1679@nanos.tec.linutronix.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: speck@linutronix.de
List-ID: <speck.linutronix.de>

> Aside of that NMIs are an interesting problem as well. You certainly don't
> want to do a synchronization dance from NMI, but ignoring NMI if you are
> paranoid is not working either because it can make very interesting data
> cache hot depending on the stuff which is monitored.

Like what interesting data? 

AFAIK NMIs do access only some non interesting kernel data structures, 
and potentially the current context if you're talking about perf's stack walking.
The current context would of course already be leakable without NMIs.

-Andi