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 ; 20 Feb 2019 16:59:37 -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 1gwVDc-0001Xb-CJ for speck@linutronix.de; Wed, 20 Feb 2019 17:59:36 +0100 Date: Wed, 20 Feb 2019 08:59:33 -0800 From: Andi Kleen Subject: [MODERATED] Re: [patch 3/8] MDS basics 3 Message-ID: <20190220165933.GY16922@tassilo.jf.intel.com> References: <20190219124406.449727187@linutronix.de> <20190219125346.051578613@linutronix.de> <20190219160450.GR16922@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: Thomas, > Please provide a conclusive technical explanation why a NMI entered from > user space and returning to that would expose sensible information to an > attacker in an exploitable way. Okay so you're not actually implementing full, like you stated earlier, but a strange undocumented minimal version of lazy. Lazy is always a trade off. Since we still run with a single address space the CPU can always do some prefetching or speculative execution and fetch something nearby that the code doesn't actually access intentionally, which may end up leaking through some buffer. In such a case even a NMI could leak. Of course such a case is unlikely, but in theory it could happen. The intention of the full option was to allow an option for people who cannot accept any risk at all. Of course that's not the right approach for most users, but for a few it might be. If you implement full you should implement it properly and not leave holes. If you're not interested in code review please state so and I will not bother anymore. -Andi