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 ; 19 Feb 2019 13:38:02 -0000 Received: from localhost ([127.0.0.1] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtp (Exim 4.80) (envelope-from ) id 1gw5az-00049v-9v for speck@linutronix.de; Tue, 19 Feb 2019 14:38:01 +0100 Message-Id: <20190219124406.449727187@linutronix.de> Date: Tue, 19 Feb 2019 13:44:06 +0100 From: Thomas Gleixner Subject: [patch 0/8] MDS basics 0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: Subject: [patch 0/8] MDS basics From: Thomas Gleixner Hi! I got the following information yesterday night: "All - FYI. There has been some chatter/ discussion on the subject. Hopefully this note will help clarify. We received a report from a researcher who independently identified what we formerly referred to as PSF (aka Microarchitectural Store Buffer Data Sampling). There were some initial indications (this week) this researcher would elect to release a paper publicly PRIOR to the May 14 embargo was lifted. We have been working closely with them, and it appears for now that will NOT be the case. Were that to happen however, we DID begin prepping materials to disclose PSF ONLY. I.e. we would disclose only that particular issue after having consulted with this team. This includes a modified/ reduced section of the existing whitepaper, press statement and standard security advisory language. We are finalizing this material and will then hold it in reserve. As we have done in the past, we would convene a meeting of reps from this group before activating those assets. I will keep you apprised of any change in the situation, and can provide those assets for your use/ adaptation once finalized." This was posted on that keybase io chat on friday night and of course not made available to those who are not part of that. Even people who are subscribed there missed the message because it scrolled away due to other chit/chat. Now we maybe got lucky this time, but I wouldn't hold my breath as the propability that other people will figure that out as well is surely way larger than 0. If that happens, then it makes exactly ZERO sense to expose only the MSBDS part as everything else is lumped together with this. But why am I still trying to make sense of all this? So while being grumpy about this communication fail, I'm even more grumpy about the fact, that we don't have even the minimal full/off mitigation in place in a workable form. I asked specifically for this weeks ago just for the case that the embargo breaks early so we don't stand there with pants down. So being grumpy as hell made me sit down and write the basic mitigation implementation myself (again). It reuses a single patch from that Intel pile which is defining the bug and MSR bits. Guess what, it took me less than 4 hours to do so and another 2 hours in the morning to write at least the basic admin documentation. The latter surely needs some work still, but I wanted to get the patches out. There is also another TODO mentioned further down. The series comes with: - A consistent command line interface - A consistent sysfs interface - Static key based control for the exit to user and idle invocations - Dynamic update of the idle invocation key according to the actual SMT state similar to the STIPB update. - Idle invocations are inside the halt/mwait inlines and not randomly sprinkled all over the kernel tree. It builds and boots and while I was able to emit the VERW instruction by hacking the mitigation selection to omit the MD_CLEAR supported check, I have no access to real hardware with updated micro code. This is how it should have looked from the very beginning and the extra bits and pieces (cond mode) can be built on top of it. Please review and give it a testride when you have a machine with updated microcode available. The lot is also available from the speck git tree in the WIP.mds branch. Note, that I moved the L!TF document to a separate folder so the hw vulnerabilities are not showing up at the top level index of the admin guide as separate items. Should have thought about that back then already... TODO: For CPUs which are not affected by L1TF but are affected by MDS there needs to be CPU buffer clear mitigation at VMENTER. That applies at least to XEON PHI, SILVERMONT and AIRMONT and probably to some of the newer models which have RDCL_NO set. Thanks, tglx 8<----------------------- Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 13 + Documentation/admin-guide/hw-vuln/l1tf.rst | 1 Documentation/admin-guide/hw-vuln/mds.rst | 230 +++++++++++++++++++++ Documentation/admin-guide/index.rst | 6 Documentation/admin-guide/kernel-parameters.txt | 27 ++ arch/x86/entry/common.c | 3 arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/irqflags.h | 4 arch/x86/include/asm/msr-index.h | 5 arch/x86/include/asm/mwait.h | 7 arch/x86/include/asm/nospec-branch.h | 22 ++ arch/x86/include/asm/processor.h | 6 arch/x86/kernel/cpu/bugs.c | 102 +++++++++ arch/x86/kernel/cpu/common.c | 13 + drivers/base/cpu.c | 6 include/linux/cpu.h | 2 17 files changed, 443 insertions(+), 7 deletions(-)