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 02:00:23 -0000 Received: from mga01.intel.com ([192.55.52.88]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gWXLQ-0001g3-PT for speck@linutronix.de; Tue, 11 Dec 2018 03:00:21 +0100 Date: Mon, 10 Dec 2018 18:00:17 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v2 2/8] MDSv2 1 Message-ID: <20181211020017.GE16024@tassilo.jf.intel.com> References: <87784B01-00DE-4E4E-AF13-7CEFC9903019@oracle.com> MIME-Version: 1.0 In-Reply-To: <87784B01-00DE-4E4E-AF13-7CEFC9903019@oracle.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: > - altinstructions are probably not what we want at all for any of these > mitigations. > > If you have a patched kernel but old microcode and then do a late load > of the microcode, you have already thrown away the alternatives by that > point and you'll show as being mitigated but in fact have nops all over > the place. A static branch would solve this. Nothing else in the Linux kernel handles changed CPUIDs from a microcode load. The microcode loader even detects this case and warns about it. The assumption was that if you update the kernel you also update the microcode, and you do it at boot. If you do hot update, you are unlikely to have the new patched kernel anyways, and if you try to hot patch the hooks in too you can handle it in your patch. But I don't see any point in complicating the upstream kernel for such hotpatch only scenarios. -Andi