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 ; 22 Jan 2019 01:22:37 -0000 Received: from mga05.intel.com ([192.55.52.43]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1glklv-0001dn-Ri for speck@linutronix.de; Tue, 22 Jan 2019 02:22:36 +0100 Date: Mon, 21 Jan 2019 17:22:33 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v5 22/27] MDSv5 24 Message-ID: <20190122012233.GS6118@tassilo.jf.intel.com> References: <5fc3209d2880402d332ec93cf076467b3706a401.1547858934.git.ak@linux.intel.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, Jan 22, 2019 at 10:24:46AM +1300, speck for Linus Torvalds wrote: > On Tue, Jan 22, 2019 at 8:57 AM speck for Andi Kleen > wrote: > > > > Instrument some strategic skbuff functions that either touch > > packet data directly, or are likely followed by a user > > data touch like a memcpy, to schedule a cpu clear on next > > kernel exit. > > I think this is crazy. > > We're marking things as "clear cpu state" for when we touch data that > WAS VISIBLE ON THE NETWORK! Well there's loopback too and it should be encrypted, but yes. There could be still a reasonable expectation that different users of the network are isolated. We could drop it, but I fear it would encourage more use of mds=full. Or perhaps do something different for loopback? Likely more complicated, but possible. > That makes no sense to me. Plus is likely hurts exactly the kinds of > loads that people don't want to hurt. I'm not sure about that actually A normal network server doing TCP/UDP shouldn't trigger it much because all the interesting operations on data are in process context, and the workloads that trigger like firewalling it are likely not doing much ring 3 code, so there won't be much clears either. I haven't done any experiments to verify that though. -Andi