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 ; 12 Dec 2018 21:43:14 -0000 Received: from mga09.intel.com ([134.134.136.24]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gXCHh-0001qY-58 for speck@linutronix.de; Wed, 12 Dec 2018 22:43:13 +0100 Date: Wed, 12 Dec 2018 13:43:10 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v2 2/8] MDSv2 1 Message-ID: <20181212214310.GI25620@tassilo.jf.intel.com> References: <87784B01-00DE-4E4E-AF13-7CEFC9903019@oracle.com> <20181211100335.GB25994@zn.tnic> <20181212213147.GR9077@char.us.oracle.com> MIME-Version: 1.0 In-Reply-To: <20181212213147.GR9077@char.us.oracle.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Dec 12, 2018 at 04:31:48PM -0500, speck for Konrad Rzeszutek Wilk wrote: > On Tue, Dec 11, 2018 at 11:03:35AM +0100, speck for Borislav Petkov wrote: > > On Mon, Dec 10, 2018 at 07:13:18PM -0500, speck for Kanth Ghatraju wrote: > > > If you have a patched kernel but old microcode and then do a late load > > > of the microcode, > > > > And to extend what the others said: late microcode loading is a can > > of worms which we shouldnt've opened back then. Especially since it > > requires a complicated dance on the OS part to quiesce the cores to even > > work without locking up the core or whatever crazy can happen. > > We (Oracle, UEK kernel) has this can of worms happily (well, we did have to > get rid of some bugs) working. > > We can start that conversation upstream, but Thomas and Boris -are you > guys very much against this idea with the upstream kernel or would you > be up for taking a sip from this can? If you really want to support it the right way would be to fix alternative() to support it natively, not require every user of alternative to switch to static keys. It's probably not that hard, just don't throw the alternative tables away and rerun the sequence. Will likely need a stop_machine to patch to handle multiple instruction sequences, but that is likely not a big issue. If that was done my patch would just work naturally without any changes. -Andi