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 ; 11 Dec 2018 03:27:17 -0000 Received: from mga04.intel.com ([192.55.52.120]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gWYfT-0002l0-5U for speck@linutronix.de; Tue, 11 Dec 2018 04:25:07 +0100 Date: Mon, 10 Dec 2018 19:25:03 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v2 3/8] MDSv2 5 Message-ID: <20181211032503.GB25620@tassilo.jf.intel.com> References: <0d6a3fbe4c511152a0f5350e62e9e09ec545f709.1544464266.git.ak@linux.intel.com> <20181211000303.GB16024@tassilo.jf.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 Mon, Dec 10, 2018 at 06:20:16PM -0800, speck for Linus Torvalds wrote: > Re-sending, because apparently the previous email was so well > encrypted that Andi couldn't even read it. > > Oh well. I was so happy to get my s/mime setup fixed up and finally > talking to the speck list automatically and properly, but I was > apparently celebrating too early, so this downgrades to the earlier > (somewhat broken) setup. > > I suspect Thomas could write a book about his frustrations by now. > > Linus > > On Mon, Dec 10, 2018 at 5:33 PM Linus Torvalds wrote: > > > > On Mon, Dec 10, 2018 at 4:43 PM Linus Torvalds wrote: > > > > > > I think the encryption key case could easily have a "let's scrub cpu state" thing. > > > > In fact, maybe we could have something like a TIF_SCRUBME thread flag, > > which we react to on return to user space, and on context switch. > > > > That way anybody who thinks they are really working with sensitive > > information could just set the flag. We could set it automatically in > > kzfree() and memzero_explicit(). > > > > Using a TIF_xyz flag would seem to be very natural. Sure, there's a > > window between the "handle TIF_xyz" flags and the actual return to > > user space, but nothing in that window should touch anything remotely > > sensitive. It's mainly just restoring user state. Okay. We'll have to disable interrupts in that window, but that should be ok. I guess it could be also set in some skb_* functions to catch the network cases. Or maybe setting when calling into unaudited code in interrupts/timers? And the flag would allow a "paranoid" mode which sets it unconditionally. -Andi