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 17:49:50 -0000 Received: from mail.kernel.org ([198.145.29.99]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gyKNt-0004oj-Dv for speck@linutronix.de; Mon, 25 Feb 2019 18:49:49 +0100 Date: Mon, 25 Feb 2019 18:49:36 +0100 From: Greg KH Subject: [MODERATED] Re: [PATCH v6 39/43] MDSv6 Message-ID: <20190225174936.GA3230@kroah.com> References: <4e5e24fd0c2111686f32a55581efa5070cf0a160.1551019522.git.ak@linux.intel.com> <20190225152654.GB19947@kroah.com> <20190225162825.GR16922@tassilo.jf.intel.com> <20190225164729.GA10883@kroah.com> <20190225170503.GU16922@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20190225170503.GU16922@tassilo.jf.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Mon, Feb 25, 2019 at 09:05:03AM -0800, speck for Andi Kleen wrote: > On Mon, Feb 25, 2019 at 05:47:29PM +0100, speck for Greg KH wrote: > > On Mon, Feb 25, 2019 at 08:28:25AM -0800, speck for Andi Kleen wrote: > > > > > Instead of marking all the USB interrupts and timers as clear cpu > > > > > only clear it when the user data touching actually happens. > > > > > > > > Um, almost all irqs here _do_ receive data across the wire, and your > > > > patch shows this happening. The text here is all wrong. > > > > > > Just to be clear touching here it means "access with the CPU" > > > especially copying. Just manipulating data addresses is fine. > > > > > > > > > > Also, why are you classifying USB data as "user data"? It's coming from > > > > some random piece of hardware. I don't see a definition of what you are > > > > calling "user data" anywhere in this patchset, did I miss that > > > > somewhere? > > > > > > user data includes IO data (but not metadata) > > > > What is "metadata" when you are dealing with a stream of scsi data over > > a random physical layer? > > Anything that's not the user visible data on disk. > > (ok perhaps checksums too, but I didn't find any driver that handles those) But typically transports mix those up, so you are going to have a hard time here if you wish to tease them apart, as Mark mentioned. > > > USB could be key presses (e.g. your password) or mouse movements or block IO data > > > > > > These are all considered sensitive. > > > > So, all USB data is sensitive, great, document that crazyness! What > > about thunderbolt data? Unipro data? amba bus data? > > Only the payloads, not the metadata. > > > Do you care about the physical layer (USB, unipro, amba, thunderbolt), > > or do you care about the "class" of data (keyboard, block, input, hid, > > camera)? Right now you seem to be mixing the two up in horridly complex > > ways that is guaranteed to drive you, and us, crazy. > > Please just use your common sense, on't play the lawyer. > > Would an attacker care about e.g. a sequence number or flags bit in some > USB header? Likely no. > > Would an attacker care about the keypress containing parts of your password? > Yes I am not trying to be a lawyer, I am trying to make this simpler and actually figure out what needs to be done here. You obviously do not care about all bus data, only some. So which "some"? As we have class drivers, why not focus on the type of data you feel is an issue? That way you have a chance to keep on top of this thing. If you only focus on a bus, then you will miss those types of things that do not use a bus. If you focus on the type of data, then you have a chance to do this right. If you can't determine this then mds=full is going to have to be the only solution. What are other operating systems going to do about all of this? Are they just punting and doing the "full" protection, or are they actually trying to mitigate this by focusing on what data types need to be protected? thanks, greg k-h