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 ; 25 Feb 2019 16:42:34 -0000 Received: from mga12.intel.com ([192.55.52.136]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gyJKq-0002X4-Ls for speck@linutronix.de; Mon, 25 Feb 2019 17:42:33 +0100 Date: Mon, 25 Feb 2019 08:42:30 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v6 10/43] MDSv6 Message-ID: <20190225164230.GS16922@tassilo.jf.intel.com> References: <20190225161141.GA22318@kroah.com> MIME-Version: 1.0 In-Reply-To: <20190225161141.GA22318@kroah.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: > 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