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

[Greg KH <gregkh@linuxfoundation.org>]

On Sun, Feb 24, 2019 at 07:07:16AM -0800, speck for Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> Subject:  mds: Add documentation for clear cpu usage
> 
> Including the theory, and some guide lines for subsystem/driver
> maintainers.

Ah, I finally found this patch in the pile...

> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
>  Documentation/clearcpu.txt | 261 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 261 insertions(+)
>  create mode 100644 Documentation/clearcpu.txt
> 
> diff --git a/Documentation/clearcpu.txt b/Documentation/clearcpu.txt
> new file mode 100644
> index 000000000000..a45e5d82868a
> --- /dev/null
> +++ b/Documentation/clearcpu.txt
> @@ -0,0 +1,261 @@
> +
> +Security model for Microarchitectural Data Sampling
> +===================================================
> +
> +Some CPUs can leave read or written data in internal buffers,
> +which then later might be sampled through side effects.
> +For more details see CVE-2018-12126 CVE-2018-12130 CVE-2018-12127
> +
> +This can be avoided by explicitly clearing the CPU state.
> +
> +We attempt to avoid leaking data between different processes,
> +and also some sensitive data, like cryptographic data, to
> +user space.
> +
> +We support three modes:
> +
> +(1) mitigation off (mds=off)
> +(2) clear only when needed (default)
> +(3) clear on every kernel exit, or guest entry (mds=full)
> +
> +(1) and (3) are trivial, the rest of the document discusses (2)
> +
> +In general option (3) is the most conservative choice. It does
> +not make ST assumptions about leaking data.
> +
> +Basic requirements and assumptions
> +----------------------------------
> +
> +Kernel addresses and kernel temporary data are not sensitive.
> +
> +User data is sensitive, but only for other processes.
> +
> +User data is anything in the user address space, or data buffers
> +directly copied from/to the user (e.g. read/write). It does not
> +include metadata, or flag settings. For example packet headers
> +or file names are not sensitive in this model.
> +
> +Block IO data (but not meta data) is sensitive.
> +
> +Most data structures in the kernel are not sensitive.
> +
> +Kernel data is sensitive when it involves cryptographic keys.
> +
> +We consider data from input devices (such as key presses)
> +sensitive. We also consider sound data or terminal
> +data sensitive.

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".

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

> +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?

thanks,

greg k-h