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:05:08 -0000 Received: from mga14.intel.com ([192.55.52.115]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gyJgg-0003Vp-RE for speck@linutronix.de; Mon, 25 Feb 2019 18:05:07 +0100 Date: Mon, 25 Feb 2019 09:05:03 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v6 39/43] MDSv6 Message-ID: <20190225170503.GU16922@tassilo.jf.intel.com> References: <4e5e24fd0c2111686f32a55581efa5070cf0a160.1551019522.git.ak@linux.intel.com> <20190225152654.GB19947@kroah.com> <20190225162825.GR16922@tassilo.jf.intel.com> <20190225164729.GA10883@kroah.com> MIME-Version: 1.0 In-Reply-To: <20190225164729.GA10883@kroah.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: 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) > > > 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 So we're trying to protect that part. I'm trying to define a model that is secure enough, but still implementable. If everyone thinks we should just go with mds=full I'm happy to drop these patches. It certainly makes everything a lot simpler! It's not that I like doing all of this personally. But as long as people think the performance benefits of the lazy approach are needed, we'll need some model like this, and some variant of these patches. -Andi