From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 23 Feb 2019 00:53:34 -0000 Received: from smtp.ctxuk.citrix.com ([185.25.65.24] helo=SMTP.EU.CITRIX.COM) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gxLZM-0000XO-Ke for speck@linutronix.de; Sat, 23 Feb 2019 01:53:33 +0100 Subject: [MODERATED] Re: [patch V4 00/11] MDS basics References: <20190222222418.405369026@linutronix.de> From: Andrew Cooper Message-ID: Date: Sat, 23 Feb 2019 00:53:23 +0000 MIME-Version: 1.0 In-Reply-To: <20190222222418.405369026@linutronix.de> Content-Type: multipart/mixed; boundary="JNlrFfUiIqjWOdhXnzlFCkjTQuykppH3R"; protected-headers="v1" To: speck@linutronix.de List-ID: --JNlrFfUiIqjWOdhXnzlFCkjTQuykppH3R Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 22/02/2019 22:24, speck for Thomas Gleixner wrote: > Hi! > > Another day, another update. > > Changes since V3: > > - Add the #DF mitigation and document why I can't be bothered > to sprinkle the buffer clear into #MC > > - Add a comment about the segment selector choice. It makes sense on = it's > own but it won't prevent anyone from thinking that we're crazy. > > - Addressed the review feedback vs. documentation > > - Resurrected the admin documentation patch, tidied it up and filled = the > gaps. > > Delta patch without the admin documentation parts below. > > Git tree WIP.mds branch is updated as well. > > If anyone of the people new to this need access to the git repo, > please send me a public SSH key so I can add to the gitolite config. > > There is one point left which I did not look into yet and I'm happy to > delegate that to the virtualization wizards: > > XEON PHI is not affected by L1TF, so it won't get the L1TF > mitigations. But it is affected by MSBDS, so it needs separate > mitigation, i.e. clearing CPU buffers on VMENTER. I haven=E2=80=99t got to this in Xen yet, but you're right - it is a pain= to deal with. For L1TF, the write to MSR_FLUSH_CMD has to be in an MSR load list if you want to avoid all kinds of nasty race conditions with late-hitting NMIs/etc in the path-to-vmentry. For PHI, it would be ideal to use the same mechanism, but obviously we cant.=C2=A0 That said - I've just asked Intel what the feasibility of get= ting MSR_FLUSH_CMD[1] being VERW is.=C2=A0 I very much expect the answer is "w= e're months too late for a question like that", but I don't lose anything by asking. In Xen, I've managed to get the VERW flushing down to a single instruction living in an alternative, and this is actually quite easy to sprinkle around the exit asm.=C2=A0 Also, because it is encoded with (%rs= p), it can be used after POPing all the GPRs on the exit path. The closer it moves to the VMLAUNCH/VMRESUME instructions, the narrower the window for race conditions (which is fairly large for L1TF as you must interact with MSRs before POPing the GPRs). An NMI happening on the instruction boundary between VERW and VMRESUME probably falls into the category of sufficiently rare to be unconcerned about[1]. ~Andrew [1] He says, fully appreciating the irony that he has spent the past 6 weeks chasing a TLB flushing bug which turned out to be an NMI hitting a single INVPCID instruction. --JNlrFfUiIqjWOdhXnzlFCkjTQuykppH3R--