[MODERATED] Re: [PATCH v6 10/43] MDSv6

[Andi Kleen <ak@linux.intel.com>]

> What do you mean by "terminal data"?
> 
> And by including stuff like "input devices", I think you need a much
> better definition of what you are now calling "user data".

It seems clear to me. Can you elaborate what exactly is unclear
and how you would define it?

> You have two types of data now, "sensitive" and "not sensitive".  Don't
> confuse things by trying to say "user", as the data coming from
> "outside" of the system (i.e. random events) might somehow be classified
> as "sensitive" in your world view here (i.e. usb random number
> generators).

Ok can change the terminology.

> 
> > +We assume that only data actually accessed by the kernel by explicit
> > +instructions can be leaked.
> 
> What do you mean by "explicit"?  A memcpy?  Setting up a DMA channel and
> processing the data afterward in userspace?  Gazing wistfully as it
> flows through the unipro fabric to and from a camera?
> 
> > Note that this may not be always
> > +true, in theory prefetching or speculation may touch more. The assumption
> > +is that if any such happens it will be very low bandwidth and hard
> > +to control due to the existing Spectre and other mitigations,
> > +such as memory randomization.  If a user is concerned about this they
> > +need to use mds=full.
> 
> Let me shorten this paragraph for you:
> 	We really have no idea what data might be touched by the
> 	processor or read by anyone else.  If you happen to care if some
> 	other process on the physical system can read your data, use
> 	mds=full.
> 
> Is that a better summary?

I don't think so.  It's a quantitative argument. It's about
rising the bar enough, while still having good performance.

For all the side channel mitigations (like Spectre v1) we used those.

But anyways so you seem to disagree with Linus' here. I'm just 
implementing what he suggested. Please argue it out with him!

-Andi