[patch 0/8] MDS basics 0

* [patch 0/8] MDS basics 0
@ 2019-02-19 12:44 Thomas Gleixner
  2019-02-19 12:44 ` [patch 1/8] MDS basics 1 Thomas Gleixner
                   ` (10 more replies)
  0 siblings, 11 replies; 42+ messages in thread
From: Thomas Gleixner @ 2019-02-19 12:44 UTC (permalink / raw)
  To: speck

Subject: [patch 0/8] MDS basics
From: Thomas Gleixner <tglx@linutronix.de>

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(-)

^ permalink raw reply	[flat|nested] 42+ messages in thread