[MODERATED] Re: Date/Time?

[Jon Masters <jcm@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3246 bytes --]

On 05/19/2018 01:26 PM, speck for Greg KH wrote:

> Jon, I know you were talking to people working on other arches, any
> ideas when I should be expecting to see patches I can backport to get
> into devices/distros?

Sorry for lag. In flight back from a funeral. Here's the latest below.
Then please see my rant (not directed at anyone here) at the end that
makes me think I should maintain a tree next time to get these to you.

* IBM p. They've an "stf-flush" patch series that protects the kernel
stack from attack by doing (effectively) a store-to-forward buffer flush
on entry into the kernel, patched with optimal code using alternatives.
It's /very/ similar to the rfi-flush code, but it doesn't rely upon
updated millicode this time. Backporting to older distros will be easier
because the heavy lifting on the entry macros was done for older kernels
the last time around. IBM know to contact Thomas, and should have
already, but I will specifically remind them AGAIN to also ping Greg. I
left the patch sending process to them. They know the parameters, etc.

That's just the kernel part. There will updated patches for userspace
and the prctl will be wired up later on. I imagine that will need some
kind of millicode but I don't yet have the plan fully from IBM there.

* IBM z. I probably shouldn't say here whether they are or are not
impacted by any of this. I can tell you that they aren't impacted by the
kernel attack since all entry into the kernel is fully serializing. They
have taken the view that they don't intend to provide any patches at
this time. I have requested an escalation within IBM on this topic.

* ARM. They have a new SMCC (Secure Monitor Call) interface (similar to
the one they did for branch predictor invalidation for Spectre-v2) that
will be wired up with kernel patches. Each of the vendors will implement
the new SMCC in ATF (Arm Trusted Firmware) on their parts, using the
best back-end mitigation (similar to microcode). Arm know to ping Thomas
with those patches, yet this has not happened yet (to my knowledge), nor
to Greg. Will has point on this in any case. He and the team are working
hard on this. Still, I am saddened by these patches not being available
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 expect
all of the SMCC wiring to be in place within the next few weeks.

And now my little rant. It is clear (to me) that Intel know how to
handle some of this better than others. The next time there is an issue,
I am going to cajole all of the vendors as usual, but I will also make
sure Greg, Linus, and Thomas are read in early enough that we can go
figure out the best way to handle the other arches. If that's me hosting
a git tree, great. Whatever you need. But we need to fix this next time.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop