From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fKof2-0005H5-0L for speck@linutronix.de; Mon, 21 May 2018 19:31:52 +0200 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 02CFF401EF07 for ; Mon, 21 May 2018 17:31:46 +0000 (UTC) Received: from washington.bos.jonmasters.org (ovpn-120-238.rdu2.redhat.com [10.10.120.238]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9D66D10EE6DA for ; Mon, 21 May 2018 17:31:45 +0000 (UTC) Subject: [MODERATED] Re: Date/Time? References: <20180519172627.GB1239@kroah.com> <20180521164655.GI17976@kroah.com> From: Jon Masters Message-ID: <5361344d-52f0-d871-5186-23cb599c0ed0@redhat.com> Date: Mon, 21 May 2018 13:31:44 -0400 MIME-Version: 1.0 In-Reply-To: <20180521164655.GI17976@kroah.com> Content-Type: multipart/mixed; boundary="i3Sahsm6sZ7lOgtwnSlCj4hWSq4lHfohe"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --i3Sahsm6sZ7lOgtwnSlCj4hWSq4lHfohe Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/21/2018 12:46 PM, speck for Greg KH wrote: > On Sun, May 20, 2018 at 04:59:04PM -0400, speck for Jon Masters wrote: >> * ARM. They have a new SMCC (Secure Monitor Call) interface (similar t= o >> the one they did for branch predictor invalidation for Spectre-v2) tha= t >> will be wired up with kernel patches. Each of the vendors will impleme= nt >> the new SMCC in ATF (Arm Trusted Firmware) on their parts, using the >> best back-end mitigation (similar to microcode). Arm know to ping Thom= as >> with those patches, yet this has not happened yet (to my knowledge), n= or >> to Greg. Will has point on this in any case. He and the team are worki= ng >> hard on this. Still, I am saddened by these patches not being availabl= e >> prior to disclosure since this is not how we do things in the server >> space. But in anticipation that this would happen, I worked directly >> with Cavium (the only server-class CPU vendor with production RHEL >> support for which we need an answer tomorrow on our end) to create a >> firmware knob that can be used in the short term until this is fixed. = I >> also have pinged all of the Arm server vendors to let them know I expe= ct >> all of the SMCC wiring to be in place within the next few weeks. >=20 > Just heard from ARM, they are going to wait a week or so and then send > patches for inclusion in 4.18 and then send some backports for the olde= r > kernels then. The kernel patches are useless without firmware updates > and I don't know what the state of them are. For the firmware, I'm told that there's a reference ATF (Arm Trusted Firmware) in flight that implements the new SMCC. I'm aware that some of the client folks have this working. On the server side, people are waiting for Arm to release the reference to them to incorporate. One of the server vendors is not impacted at all, while three others are to differing levels, and all can implement the SMCC but may also provide more optimal per-platform fixes via the errata infrastructure. I've been working with Cavium (as the only supported platform with RHEL today - we only ship subscriptions with Tier 1 OEMs, the others you can kick the tires on but no support yet) on plans and we came to a decision that we would use the emergency knob in the short term, then give Arm a few weeks to get the ATF reference out. If they don't have that done within the next few weeks, at least for Cavium/HPE it'll be done separately implementing the SMCC as we're not waiting around. Jon. --=20 Computer Architect | Sent from my Fedora powered laptop --i3Sahsm6sZ7lOgtwnSlCj4hWSq4lHfohe--