From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 27 Oct 2019 07:49:12 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iOdIU-0003Qw-JY for speck@linutronix.de; Sun, 27 Oct 2019 08:49:11 +0100 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D0000AFBC for ; Sun, 27 Oct 2019 07:49:02 +0000 (UTC) Date: Sun, 27 Oct 2019 08:48:51 +0100 From: Borislav Petkov Subject: [MODERATED] Re: [PATCH 3/9] TAA 3 Message-ID: <20191027074851.GA4951@zn.tnic> References: <580e02757c3e639bff00fcea830aa46eba46a92f.1571905227.git.bp@suse.de> <6f1ab744-622c-179b-276b-5506b2fd9ae1@citrix.com> <20191024194503.GH14115@zn.tnic> <38430127-3ece-dc06-2264-6b3bc347b523@citrix.com> <20191024201748.GL14115@zn.tnic> <832cb284-9852-5cfe-b71c-c3a23b85adc5@citrix.com> <20191025071746.GA22381@zn.tnic> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: speck@linutronix.de List-ID: On Fri, Oct 25, 2019 at 10:08:41AM +0100, speck for Andrew Cooper wrote: > Its the perfect example here.=C2=A0 The answer is by requesting that Intel > change bit 0's behaviour from causing #UD's to causing aborts. >=20 > The first version of this microcode was definitely not safe to late load. Yap, exactly, and that is a problem: you can't always get the microcode update to do what you want. IOW, we need some sort of communication protocl between CPU vendors and OS which tells the OS what the microcode provides and the OS can determine whether late loading would succeed. tglx proposed a table of CPUID feature bits changing, for example, and that is a first step in the right direction. Changing the kernel to "reload" features is not trivial. > Some userspace apparently gets confused when CPUID changes behind its > back, which is why the CPUID control in bit 1 was split out from an > otherwise monolithic bit 0. >=20 > At late load, choose (or not) to use bit 0 only. > At boot, choose (or not) both bits 0 and 1 in unison. Yes, and the fact that there are two bits is practically dictated by the inability of the OS to handle late loading optimally. Otherwise, you would've had only one bit. All I'm saying is, late loading is such a problem that it even dictates how microcode should look like. > Noone has guaranteed that all microcode ever in the future is going to > be safe to use on a running system.=C2=A0 If it really can't be made to be > safe, then customers are really going to have to reboot. >=20 > However, there is a lot of effort going into trying to make sure that > fixes such as this one are made safe for late loading. >=20 > To give a concrete example, we have customers who's elapsed time for a > reboot, conforming to SLAs, is in excess of 9 months, and new microcode > with critical fixes is coming out faster than that.=C2=A0 I bet that I'm not > the only person on this list with this type of customer. Oh I bet. And I really think in the age of containers and live migration and all that crap, what we should push for is freeing the host for proper kernel and microcode update and then rebooting it. While the guests are moved to another instance which has been rebooted already. I know, that is hard and it has its warts too but the late loading is a PITA already. And rebooting the host as part of maint downtime would give you a lot more advantages. But that's a whole another topic for another time and place. --=20 Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imend=C3=B6rffer, HRB 36809, = AG N=C3=BCrnberg --=20