From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.eu.citrix.com ([185.25.65.24]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fOANu-00033a-9A for speck@linutronix.de; Thu, 31 May 2018 01:20:03 +0200 Subject: [MODERATED] Re: [PATCH 2/2] L1TF KVM 2 References: <20180529194214.2600-1-pbonzini@redhat.com> <20180529194322.8B56F610F8@crypto-ml.lab.linutronix.de> <5f5ee0f8-ac8f-fdee-900c-7a2fed532053@citrix.com> <20180530211030.GH30764@tassilo.jf.intel.com> From: Andrew Cooper Message-ID: <2b0b261e-a4fb-29f5-c7f8-fed03d35f7ed@citrix.com> Date: Thu, 31 May 2018 00:19:53 +0100 MIME-Version: 1.0 In-Reply-To: <20180530211030.GH30764@tassilo.jf.intel.com> Content-Type: multipart/mixed; boundary="vfMn4ez4gJQK9rIFAbJ5RtJBQUg8xULEr"; protected-headers="v1" To: speck@linutronix.de List-ID: --vfMn4ez4gJQK9rIFAbJ5RtJBQUg8xULEr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 30/05/2018 22:10, speck for Andi Kleen wrote: >> Right, but you really have to make a judgement whether this leak is us= eful >> and can be orchestrated by the attacker in the guest. If it's just the= >> theoretical cornercase with no practical attack surface then you reall= y can >> leave that as an exercise for ivory tower people. > We care about user data and kernel secrets like keys. > > NMIs don't have either. > > (except for profile NMIs, but they only have the data of what > you just interrupted) > > Same for machine checks etc.=20 > > In fact most hard interrupts are likely uninteresting (except those > that copy user data), although soft interrupts may not be. Until we have instructions for how to turn off next-page prefetch (Haswell and later, I believe), *any* memory access is liable to pull in unrelated data from adjacent pages.=A0 Accesses into the directmap are liable to pull in data from a completely unrelated context, which in Xen's case has a reasonable chance of being data from another VM, and in Linux's case, data from another process. Even with regular prefetching, you're highly likely to pull in a cache line or two from an adjacent heap object. Maybe I am being too pessimistic, but at this point I don't buy the argument of "architecturally, we don't touch any sensitive data, therefore it won't be the cache".=A0 Whether said data is usefully extractable by an attacker is a different matter, but I don't feel comfortable betting peoples data isolation on the expectation that it isn't extractable. ~Andrew --vfMn4ez4gJQK9rIFAbJ5RtJBQUg8xULEr--