* [MODERATED] Date/Time? @ 2018-05-19 17:26 Greg KH 2018-05-19 17:51 ` [MODERATED] Date/Time? Borislav Petkov ` (3 more replies) 0 siblings, 4 replies; 41+ messages in thread From: Greg KH @ 2018-05-19 17:26 UTC (permalink / raw) To: speck Ok, last I heard it's the 21st, this Monday, right? Any specific timezone that applies to? 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? thanks, greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 17:26 [MODERATED] Date/Time? Greg KH @ 2018-05-19 17:51 ` Borislav Petkov 2018-05-19 18:45 ` Linus Torvalds 2018-05-19 18:21 ` David Woodhouse ` (2 subsequent siblings) 3 siblings, 1 reply; 41+ messages in thread From: Borislav Petkov @ 2018-05-19 17:51 UTC (permalink / raw) To: speck On Sat, May 19, 2018 at 07:26:27PM +0200, speck for Greg KH wrote: > Ok, last I heard it's the 21st, this Monday, right? > > Any specific timezone that applies to? Says here: "May 21st 2100 UTC". -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 17:51 ` [MODERATED] Date/Time? Borislav Petkov @ 2018-05-19 18:45 ` Linus Torvalds 2018-05-19 19:07 ` [MODERATED] " Borislav Petkov 2018-05-20 20:58 ` Jon Masters 0 siblings, 2 replies; 41+ messages in thread From: Linus Torvalds @ 2018-05-19 18:45 UTC (permalink / raw) To: speck On Sat, 19 May 2018, speck for Borislav Petkov wrote: > > Says here: "May 21st 2100 UTC". What an odd time. It's noon in the Aleutian Islands and absolutely nowhere else that I can find. I guess it's "after trading closes", but that would be 4pm eastern. And 2100 UTC is 5pm EDT, so it's _really_ after. So I wonder why that particular choice. Whatever. It's 2pm for me. I guess it's 11pm for Greg in Paris. Are we sure that's not a typo, and it's supposed to be noon UTC, transposing the two digits? Linus ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Re: Date/Time? 2018-05-19 18:45 ` Linus Torvalds @ 2018-05-19 19:07 ` Borislav Petkov 2018-05-19 19:48 ` Linus Torvalds 2018-05-20 20:58 ` Jon Masters 1 sibling, 1 reply; 41+ messages in thread From: Borislav Petkov @ 2018-05-19 19:07 UTC (permalink / raw) To: speck On Sat, May 19, 2018 at 11:45:38AM -0700, speck for Linus Torvalds wrote: > So I wonder why that particular choice. > > Whatever. It's 2pm for me. I guess it's 11pm for Greg in Paris. > > Are we sure that's not a typo, and it's supposed to be noon UTC, > transposing the two digits? Another post from our sec. guys here says: "May 21 1400 Pacific which is around CRD: 2018-05-21 21:00 UTC or 2300 CET" and 14:00 pacific is 2pm your time, right? Maybe someone from Intel could confirm. As to why, I think maybe because they didn't want to totally destroy the holiday of people where Monday the 21st is an official holiday. :-) -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Re: Date/Time? 2018-05-19 19:07 ` [MODERATED] " Borislav Petkov @ 2018-05-19 19:48 ` Linus Torvalds 2018-05-19 20:22 ` [MODERATED] " Borislav Petkov 0 siblings, 1 reply; 41+ messages in thread From: Linus Torvalds @ 2018-05-19 19:48 UTC (permalink / raw) To: speck On Sat, 19 May 2018, speck for Borislav Petkov wrote: > > Another post from our sec. guys here says: > > "May 21 1400 Pacific Ok, so that matches. > As to why, I think maybe because they didn't want to totally destroy the > holiday of people where Monday the 21st is an official holiday. End of Shavuot? Pentecost Monday? Random day of Ramadan? Canadian {Victoria, National Patriots'} Day? Oh, it's "National Strawberries and Cream Day" in the US. Yes, we wouldn't want to interrupt _that_. Anyway, not being religious, Canadian, _or_ particularly fanatical about Strawberries and Cream, I guess I really don't care. 2pm works fine for me. [ Hmm, 2100UTC literally is "midnight in Jerusalem". So it actually probably *is* "End of Shavout", and the time was picked for Orthodox Jews. And I thought I was kidding when I looked up the date at first. ] Linus ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 19:48 ` Linus Torvalds @ 2018-05-19 20:22 ` Borislav Petkov 0 siblings, 0 replies; 41+ messages in thread From: Borislav Petkov @ 2018-05-19 20:22 UTC (permalink / raw) To: speck On Sat, May 19, 2018 at 12:48:34PM -0700, speck for Linus Torvalds wrote: > End of Shavuot? Pentecost Monday? Random day of Ramadan? Canadian > {Victoria, National Patriots'} Day? > > Oh, it's "National Strawberries and Cream Day" in the US. Yes, we wouldn't > want to interrupt _that_. LOL! Strawberries and cream just don't taste as good with store bypass chunks speculatively sprinkled ontop. ;-P But yeah, it is Pentecost Monday here in .de. > Anyway, not being religious, Canadian, _or_ particularly fanatical about > Strawberries and Cream, I guess I really don't care. 2pm works fine for > me. Ah, you wanna know when to push out the speck pile you've gotten from tglx, right. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 18:45 ` Linus Torvalds 2018-05-19 19:07 ` [MODERATED] " Borislav Petkov @ 2018-05-20 20:58 ` Jon Masters 1 sibling, 0 replies; 41+ messages in thread From: Jon Masters @ 2018-05-20 20:58 UTC (permalink / raw) To: speck [-- Attachment #1: Type: text/plain, Size: 907 bytes --] On 05/19/2018 02:45 PM, speck for Linus Torvalds wrote: > > > On Sat, 19 May 2018, speck for Borislav Petkov wrote: >> >> Says here: "May 21st 2100 UTC". > > What an odd time. It's noon in the Aleutian Islands and absolutely nowhere > else that I can find. > > I guess it's "after trading closes", but that would be 4pm eastern. And > 2100 UTC is 5pm EDT, so it's _really_ after. > > So I wonder why that particular choice. > > Whatever. It's 2pm for me. I guess it's 11pm for Greg in Paris. > > Are we sure that's not a typo, and it's supposed to be noon UTC, > transposing the two digits? It's 2pm PDT because Intel asked GPZ if "21st" could mean "the afternoon of the 21st" in order to allow various CERT briefings and the like. It was apparently deemed reasonable by the Google powers that be. Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 17:26 [MODERATED] Date/Time? Greg KH 2018-05-19 17:51 ` [MODERATED] Date/Time? Borislav Petkov @ 2018-05-19 18:21 ` David Woodhouse 2018-05-19 19:05 ` Greg KH ` (2 more replies) 2018-05-20 17:45 ` Jiri Kosina 2018-05-20 20:59 ` Jon Masters 3 siblings, 3 replies; 41+ messages in thread From: David Woodhouse @ 2018-05-19 18:21 UTC (permalink / raw) To: speck On Sat, 2018-05-19 at 19:26 +0200, speck for Greg KH wrote: > Ok, last I heard it's the 21st, this Monday, right? > > Any specific timezone that applies to? > > 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? I'm putting together a 4.9 backport over the weekend and Monday morning. ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 18:21 ` David Woodhouse @ 2018-05-19 19:05 ` Greg KH 2018-05-20 19:23 ` David Woodhouse 2018-05-20 23:01 ` David Woodhouse 2 siblings, 0 replies; 41+ messages in thread From: Greg KH @ 2018-05-19 19:05 UTC (permalink / raw) To: speck On Sat, May 19, 2018 at 07:21:11PM +0100, speck for David Woodhouse wrote: > On Sat, 2018-05-19 at 19:26 +0200, speck for Greg KH wrote: > > Ok, last I heard it's the 21st, this Monday, right? > > > > Any specific timezone that applies to? > > > > 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? > > I'm putting together a 4.9 backport over the weekend and Monday > morning. Thanks for this, I started it but ran into some problems and then got distracted when someone mentioned that you might be willing to do a patch that can be tested well :) greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 18:21 ` David Woodhouse 2018-05-19 19:05 ` Greg KH @ 2018-05-20 19:23 ` David Woodhouse 2018-05-20 23:01 ` David Woodhouse 2 siblings, 0 replies; 41+ messages in thread From: David Woodhouse @ 2018-05-20 19:23 UTC (permalink / raw) To: speck On Sat, 2018-05-19 at 19:21 +0100, speck for David Woodhouse wrote: > On Sat, 2018-05-19 at 19:26 +0200, speck for Greg KH wrote: > > > > Ok, last I heard it's the 21st, this Monday, right? > > > > Any specific timezone that applies to? > > > > 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? > > I'm putting together a 4.9 backport over the weekend and Monday > morning. As I go through this, I note we seem to have have gained a bunch of this kind of thing (comments added by me): if (…) wrmsr(); /* else speculate happily over that conditional branch as if the wrmsr had never happened ... */ Are we sure those are all OK? ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 18:21 ` David Woodhouse 2018-05-19 19:05 ` Greg KH 2018-05-20 19:23 ` David Woodhouse @ 2018-05-20 23:01 ` David Woodhouse 2018-05-21 8:35 ` Greg KH 2 siblings, 1 reply; 41+ messages in thread From: David Woodhouse @ 2018-05-20 23:01 UTC (permalink / raw) To: speck On Sat, 2018-05-19 at 19:21 +0100, speck for David Woodhouse wrote: > On Sat, 2018-05-19 at 19:26 +0200, speck for Greg KH wrote: > > > > Ok, last I heard it's the 21st, this Monday, right? > > > > Any specific timezone that applies to? > > > > 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? > > I'm putting together a 4.9 backport over the weekend and Monday > morning. I've just pushed this to the linux-4.9.y branch of Thomas's git tree. It's basically untested except for the fact that it builds (for x86_64). I'll do some testing in the morning. ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 23:01 ` David Woodhouse @ 2018-05-21 8:35 ` Greg KH 0 siblings, 0 replies; 41+ messages in thread From: Greg KH @ 2018-05-21 8:35 UTC (permalink / raw) To: speck On Mon, May 21, 2018 at 12:01:02AM +0100, speck for David Woodhouse wrote: > > > On Sat, 2018-05-19 at 19:21 +0100, speck for David Woodhouse wrote: > > On Sat, 2018-05-19 at 19:26 +0200, speck for Greg KH wrote: > > > > > > Ok, last I heard it's the 21st, this Monday, right? > > > > > > Any specific timezone that applies to? > > > > > > 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? > > > > I'm putting together a 4.9 backport over the weekend and Monday > > morning. > > I've just pushed this to the linux-4.9.y branch of Thomas's git tree. > It's basically untested except for the fact that it builds (for > x86_64). I'll do some testing in the morning. At first glance, it looks good (53 patches!!!). I've grabbed the 1 prerequisite patch that is already upstream now. Thanks a lot for these. greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 17:26 [MODERATED] Date/Time? Greg KH 2018-05-19 17:51 ` [MODERATED] Date/Time? Borislav Petkov 2018-05-19 18:21 ` David Woodhouse @ 2018-05-20 17:45 ` Jiri Kosina 2018-05-20 18:19 ` Greg KH 2018-05-20 20:59 ` Jon Masters 3 siblings, 1 reply; 41+ messages in thread From: Jiri Kosina @ 2018-05-20 17:45 UTC (permalink / raw) To: speck On Sat, 19 May 2018, 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? FWIW we have 4.4 port, let me know if you want it. But it's based on our SLE kernel, which also contains the IBRS stuff, so it'd need some minor tweaking so that it applies to kernel without IBRS. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 17:45 ` Jiri Kosina @ 2018-05-20 18:19 ` Greg KH 2018-05-20 18:35 ` Borislav Petkov 2018-05-20 18:36 ` Linus Torvalds 0 siblings, 2 replies; 41+ messages in thread From: Greg KH @ 2018-05-20 18:19 UTC (permalink / raw) To: speck On Sun, May 20, 2018 at 07:45:20PM +0200, speck for Jiri Kosina wrote: > On Sat, 19 May 2018, 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? > > FWIW we have 4.4 port, let me know if you want it. > > But it's based on our SLE kernel, which also contains the IBRS stuff, so > it'd need some minor tweaking so that it applies to kernel without IBRS. Why wouldn't I also want the IBRS stuff for the upstream 4.4.y? Am I missing patches that I should have backported but didn't? And yes, I do want it if you have it :) thanks, greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 18:19 ` Greg KH @ 2018-05-20 18:35 ` Borislav Petkov 2018-05-20 19:57 ` Greg KH 2018-05-20 18:36 ` Linus Torvalds 1 sibling, 1 reply; 41+ messages in thread From: Borislav Petkov @ 2018-05-20 18:35 UTC (permalink / raw) To: speck On Sun, May 20, 2018 at 08:19:34PM +0200, speck for Greg KH wrote: > Why wouldn't I also want the IBRS stuff for the upstream 4.4.y? Because the IBRS stuff is not upstream. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 18:35 ` Borislav Petkov @ 2018-05-20 19:57 ` Greg KH 0 siblings, 0 replies; 41+ messages in thread From: Greg KH @ 2018-05-20 19:57 UTC (permalink / raw) To: speck On Sun, May 20, 2018 at 08:35:27PM +0200, speck for Borislav Petkov wrote: > On Sun, May 20, 2018 at 08:19:34PM +0200, speck for Greg KH wrote: > > Why wouldn't I also want the IBRS stuff for the upstream 4.4.y? > > Because the IBRS stuff is not upstream. Ah, that stuff. Yeah, no, I don't want that "batshit crazy stuff" in the 4.4.y tree, to quote someone :) thanks, greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 18:19 ` Greg KH 2018-05-20 18:35 ` Borislav Petkov @ 2018-05-20 18:36 ` Linus Torvalds 2018-05-20 18:48 ` Jiri Kosina 1 sibling, 1 reply; 41+ messages in thread From: Linus Torvalds @ 2018-05-20 18:36 UTC (permalink / raw) To: speck On Sun, 20 May 2018, speck for Greg KH wrote: > > Why wouldn't I also want the IBRS stuff for the upstream 4.4.y? Am I > missing patches that I should have backported but didn't? I think Jiri is talking about the bat-shit-crazy stuff that I refused to take upstream. The stuff that adds thousands of cycles to every kernel entry and doesn't actually fix any real problem except for "but but in theory" PR problems. Linus ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 18:36 ` Linus Torvalds @ 2018-05-20 18:48 ` Jiri Kosina 0 siblings, 0 replies; 41+ messages in thread From: Jiri Kosina @ 2018-05-20 18:48 UTC (permalink / raw) To: speck On Sun, 20 May 2018, speck for Linus Torvalds wrote: > > Why wouldn't I also want the IBRS stuff for the upstream 4.4.y? Am I > > missing patches that I should have backported but didn't? > > I think Jiri is talking about the bat-shit-crazy stuff that I refused to > take upstream. The stuff that adds thousands of cycles to every kernel > entry and doesn't actually fix any real problem except for "but but in > theory" PR problems. Yes, that is exactly the one :) We are providing the option of toggling the IBRS on kernel entry/exit only on CPUs that can fall back to using (potentially) poisoned indirect branch predictor in case of RSB underflow (Skylake; fortunately on those CPUs the IBRS overhead is considerably lower than on other CPUs) if the user/admin wants to. And that is the same MSR as SSBD, so there will be some minor conflicts to resolve. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-19 17:26 [MODERATED] Date/Time? Greg KH ` (2 preceding siblings ...) 2018-05-20 17:45 ` Jiri Kosina @ 2018-05-20 20:59 ` Jon Masters 2018-05-20 21:09 ` Jiri Kosina ` (3 more replies) 3 siblings, 4 replies; 41+ messages in thread From: Jon Masters @ 2018-05-20 20:59 UTC (permalink / raw) To: speck [-- 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 20:59 ` Jon Masters @ 2018-05-20 21:09 ` Jiri Kosina 2018-05-21 6:11 ` Greg KH 2018-05-20 21:48 ` Linus Torvalds ` (2 subsequent siblings) 3 siblings, 1 reply; 41+ messages in thread From: Jiri Kosina @ 2018-05-20 21:09 UTC (permalink / raw) To: speck On Sun, 20 May 2018, speck for Jon Masters wrote: > * 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. FWIW we already have the port of this to 4.12, 4.4 and 3.0 in case -stable would like to have these before IBM submits it properly. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 21:09 ` Jiri Kosina @ 2018-05-21 6:11 ` Greg KH 0 siblings, 0 replies; 41+ messages in thread From: Greg KH @ 2018-05-21 6:11 UTC (permalink / raw) To: speck On Sun, May 20, 2018 at 11:09:08PM +0200, speck for Jiri Kosina wrote: > On Sun, 20 May 2018, speck for Jon Masters wrote: > > > * 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. > > FWIW we already have the port of this to 4.12, 4.4 and 3.0 in case -stable > would like to have these before IBM submits it properly. Thanks for the offer, but I'll wait until they hit Linus's tree. Odds are Debian might want these patches, if you have them, so maybe posting them somewhere after the deadline will be helpful for them. thanks, greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 20:59 ` Jon Masters 2018-05-20 21:09 ` Jiri Kosina @ 2018-05-20 21:48 ` Linus Torvalds 2018-05-20 21:56 ` David Woodhouse 2018-05-21 6:16 ` Greg KH 2018-05-21 16:46 ` [MODERATED] Date/Time? Greg KH 3 siblings, 1 reply; 41+ messages in thread From: Linus Torvalds @ 2018-05-20 21:48 UTC (permalink / raw) To: speck On Sun, 20 May 2018, speck for Jon Masters wrote: > > And now my little rant. It is clear (to me) that Intel know how to > handle some of this better than others. Hahhahahaaaa! <Wipes tears from eyes, not sure whether from laughing or crying>. Yeah, Intel has been great. Snort. They did learn something from last time, I think, and that made them more open to some things. But I really think it's mostly because Thomas has been pushing it. Look at where this mailing list is hosted, for example, just to pick one random detail. Linus ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 21:48 ` Linus Torvalds @ 2018-05-20 21:56 ` David Woodhouse 0 siblings, 0 replies; 41+ messages in thread From: David Woodhouse @ 2018-05-20 21:56 UTC (permalink / raw) To: speck On Sun, 2018-05-20 at 14:48 -0700, speck for Linus Torvalds wrote: > They did learn something from last time, I think, and that made them more > open to some things. But I really think it's mostly because Thomas has > been pushing it. Look at where this mailing list is hosted, for example, > just to pick one random detail. OK, it was only one example of many but really... if Intel ever offer to host anything email-related for you, say no. :) There's a reason I was giving Intel people functional email accounts long before I ever started working there, and continue to do so even after I stopped. ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 20:59 ` Jon Masters 2018-05-20 21:09 ` Jiri Kosina 2018-05-20 21:48 ` Linus Torvalds @ 2018-05-21 6:16 ` Greg KH 2018-05-21 7:18 ` David Woodhouse 2018-05-21 16:46 ` [MODERATED] Date/Time? Greg KH 3 siblings, 1 reply; 41+ messages in thread From: Greg KH @ 2018-05-21 6:16 UTC (permalink / raw) To: speck On Sun, May 20, 2018 at 04:59:04PM -0400, speck for Jon Masters wrote: > 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. <snip of the summary> Thanks for this, much appreciated. Sad to see there is no other arch that is going to be ready, wonderful :( > 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. As Linus said, hah! Intel only "handled this better" because of Thomas pushing them (the effort it took to get me here was crazy...) And I doubt we need another git tree, we already have one, that should have worked for any arch that needed it. The problem seems to be that those developers were not "allowed" here for us to work together, exactly like last time. Oh well, baby steps, maybe next time will be better, but I'm not holding my breath. greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 6:16 ` Greg KH @ 2018-05-21 7:18 ` David Woodhouse 2018-05-21 15:23 ` Date/Time? Thomas Gleixner 0 siblings, 1 reply; 41+ messages in thread From: David Woodhouse @ 2018-05-21 7:18 UTC (permalink / raw) To: speck On Mon, 2018-05-21 at 08:16 +0200, speck for Greg KH wrote: > And I doubt we need another git tree, we already have one, that should > have worked for any arch that needed it. The problem seems to be that > those developers were not "allowed" here for us to work together, > exactly like last time. If that is 100% known to be the case, then it should be part of our messaging when we release. "Here are patches for x86. Other architectures are not yet covered because their maintainers were not permitted to work with the pre- embargo team for corporate bullshit reasons." I'm sure Linus can phrase that sentiment just as well as I can... :) After the requisite whining from pointyhairs at the companies concerned, it will lead to their engineers being allowed to do the right thing next time. We *do* have to be sure it's true, of course. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Date/Time? 2018-05-21 7:18 ` David Woodhouse @ 2018-05-21 15:23 ` Thomas Gleixner 0 siblings, 0 replies; 41+ messages in thread From: Thomas Gleixner @ 2018-05-21 15:23 UTC (permalink / raw) To: speck [-- Attachment #1: Type: text/plain, Size: 2138 bytes --] On Mon, 21 May 2018, speck for David Woodhouse wrote: > On Mon, 2018-05-21 at 08:16 +0200, speck for Greg KH wrote: > > > And I doubt we need another git tree, we already have one, that should > > have worked for any arch that needed it. The problem seems to be that > > those developers were not "allowed" here for us to work together, > > exactly like last time. > > If that is 100% known to be the case, then it should be part of our > messaging when we release. We could have created yet another crypto mailing list to have the others on board for GPZ4 because they are not allowed to hear about the L1 still embargoed (Intel only) crap. I pondered it for a bit, but then decided not to as its already bad enough to have one crypto list to deal with. And dealing with the extra nonsense of figuring out which list is for what and then having parallel discussions about the same thing on both lists is just not workable. I gave them access to the sysfs/prctl/seccomp and command line bits though, so they could align their work on ours. I offered them to merge their stuff through the sekrit git repo, but they have their own plans it seems. I told Intel that we want the others here and that we can stop talking about the L1 fuckup until GPZ4 is public and Intel agreed. That was at least 4 weeks ago. But the only two people who were allowed on the list are Tom Lendacky and Alexei Starovoitov. The ARM/PowerPC people were still under discussion @Intel end of last week. Useful... Getting Tom in took only 3 weeks. For Greg it was 6 weeks and I had to push hard to get it done. Alexei was pushed through by Dave Hansen, no idea how long it took him to get there. So in general the situation was more workable than last time, but far from being great. The right thing for stuff like this is treating us as adult and responsible people and let us work it out on our own without being babysitted by Intel and their disfunctional and agonizingly slow bureaucraZy. Seriously, the whole foofaraw about the L1 fuckup is just an idiotic secrecy spectacle. Thanks, tglx ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-20 20:59 ` Jon Masters ` (2 preceding siblings ...) 2018-05-21 6:16 ` Greg KH @ 2018-05-21 16:46 ` Greg KH 2018-05-21 17:12 ` Konrad Rzeszutek Wilk ` (3 more replies) 3 siblings, 4 replies; 41+ messages in thread From: Greg KH @ 2018-05-21 16:46 UTC (permalink / raw) To: speck 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 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. 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 older kernels then. The kernel patches are useless without firmware updates and I don't know what the state of them are. They also complained that they can not finalize their patches as they do not know what we agreed on for the prctl() interface. Which sucks as that was hashed out here weeks ago. Another proof of how when we are not "allowed" to talk to the right people, Linux users suffer. That is not ok. thanks, greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 16:46 ` [MODERATED] Date/Time? Greg KH @ 2018-05-21 17:12 ` Konrad Rzeszutek Wilk 2018-05-21 19:42 ` Greg KH 2018-05-21 17:22 ` Jon Masters ` (2 subsequent siblings) 3 siblings, 1 reply; 41+ messages in thread From: Konrad Rzeszutek Wilk @ 2018-05-21 17:12 UTC (permalink / raw) To: speck > They also complained that they can not finalize their patches as they do > not know what we agreed on for the prctl() interface. Which sucks as > that was hashed out here weeks ago. They weren't on keybase? I've religiously been telling folks what is done upstream along with the patches so that this would _not_ occur! This is on the 'spectre_meltdown' keybase channel. <sighs> > > Another proof of how when we are not "allowed" to talk to the right > people, Linux users suffer. That is not ok. > > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 17:12 ` Konrad Rzeszutek Wilk @ 2018-05-21 19:42 ` Greg KH 2018-05-21 19:48 ` Jiri Kosina 0 siblings, 1 reply; 41+ messages in thread From: Greg KH @ 2018-05-21 19:42 UTC (permalink / raw) To: speck On Mon, May 21, 2018 at 01:12:40PM -0400, speck for Konrad Rzeszutek Wilk wrote: > > They also complained that they can not finalize their patches as they do > > not know what we agreed on for the prctl() interface. Which sucks as > > that was hashed out here weeks ago. > > They weren't on keybase? I've religiously been telling folks what is done > upstream along with the patches so that this would _not_ occur! > > This is on the 'spectre_meltdown' keybase channel. Before an hour ago, I didn't know what "keybase" was. Now that I do know, I have no idea how in the world anyone submitted kernel patches using it for ARM people to be basing their code on. Come on people, be sane here. The ARM developers said they only got the patches through a back-channel, which sounds like what the keybase chat was. But it wasn't good enough and I don't blame them. ugh. Oh well, good thing that no one cares about ARM servers :( thanks, greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 19:42 ` Greg KH @ 2018-05-21 19:48 ` Jiri Kosina 2018-05-21 20:30 ` Jon Masters 0 siblings, 1 reply; 41+ messages in thread From: Jiri Kosina @ 2018-05-21 19:48 UTC (permalink / raw) To: speck On Mon, 21 May 2018, speck for Greg KH wrote: > Before an hour ago, I didn't know what "keybase" was. Now that I do > know, I have no idea how in the world anyone submitted kernel patches > using it for ARM people to be basing their code on. If Thomas wouldn't set up this list, apparently everything would be happening just on this keybase (whatever that is). I was a bit shocked in the early phases indeed. I find it rather ironic that for discussing stuff that allows external websites to steal encryption keys from your browser ... you use ... *drumroll* ... external website :) -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 19:48 ` Jiri Kosina @ 2018-05-21 20:30 ` Jon Masters 2018-05-22 8:00 ` Peter Zijlstra 0 siblings, 1 reply; 41+ messages in thread From: Jon Masters @ 2018-05-21 20:30 UTC (permalink / raw) To: speck [-- Attachment #1: Type: text/plain, Size: 2038 bytes --] On 05/21/2018 03:48 PM, speck for Jiri Kosina wrote: > On Mon, 21 May 2018, speck for Greg KH wrote: > >> Before an hour ago, I didn't know what "keybase" was. Now that I do >> know, I have no idea how in the world anyone submitted kernel patches >> using it for ARM people to be basing their code on. > > If Thomas wouldn't set up this list, apparently everything would be > happening just on this keybase (whatever that is). I was a bit shocked in > the early phases indeed. > I find it rather ironic that for discussing stuff that allows external > websites to steal encryption keys from your browser ... you use ... > *drumroll* ... external website :) Let's skip the FUD tho. It's not a "website". It's an open source end-to-end encrypted chat application. Its purpose was never to share patches anyway, just for coordination of issues (you can attach files, but that was only for convenience). Keybase also wasn't my idea, but I don't have a problem with it as a useful means of getting many parties collaborating on coordinated disclosure (think of it as IRC but with an attempt at actual security that Google, Intel, and others were ok with using). At the same time, it's great tglx setup this list for Linux patch discussion. They aren't both trying to solve the same thing. Specifically on the other arches, at the time they needed to know what to work on, there was no mailing list anyway (this list wasn't setup for v4 specific discussion at that time, so those folks could not have been added to it anyway). They received a copy of the work in progress, by email as well, and were part of the ongoing discussion so did know each time Konrad mentioned an updated patch was available. Various of us also sent copies of the patches. Folks certainly knew who to ping for help. Regardless of how things should or should not be done, folks were certainly well aware that things were coming today, months ago. Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 20:30 ` Jon Masters @ 2018-05-22 8:00 ` Peter Zijlstra 2018-05-22 9:26 ` Greg KH 0 siblings, 1 reply; 41+ messages in thread From: Peter Zijlstra @ 2018-05-22 8:00 UTC (permalink / raw) To: speck On Mon, May 21, 2018 at 04:30:27PM -0400, speck for Jon Masters wrote: > Let's skip the FUD tho. It's not a "website". It's an open source > end-to-end encrypted chat application. But it is not packaged by any distro afaik, so you basically have to trust their webshite to fetch a binary, which is pretty dodgy if you ask me. Also, keybase is pretty terrible UI wise.. ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-22 8:00 ` Peter Zijlstra @ 2018-05-22 9:26 ` Greg KH 2018-05-22 16:32 ` Andi Kleen 2018-05-23 14:15 ` Jon Masters 0 siblings, 2 replies; 41+ messages in thread From: Greg KH @ 2018-05-22 9:26 UTC (permalink / raw) To: speck On Tue, May 22, 2018 at 10:00:35AM +0200, speck for Peter Zijlstra wrote: > On Mon, May 21, 2018 at 04:30:27PM -0400, speck for Jon Masters wrote: > > Let's skip the FUD tho. It's not a "website". It's an open source > > end-to-end encrypted chat application. > > But it is not packaged by any distro afaik, so you basically have to > trust their webshite to fetch a binary, which is pretty dodgy if you ask > me. You mean you don't trust the "run a random binary from the internet as root?" instructions they provide you: https://keybase.io/docs/the_app/install_linux :( And Jon, it's not "FUD" it's the apparent hypocrisy of some companies INSISTING on keeping things "secure" and then they go and place the patches created here up on a random location/site and insist on all security people from all companies run some random binary as root just to talk about when they might be releasing things and what to do next and when they should all meet up for beer when they are in town. If I wanted to Trojan a whole bunch of people that really should know better, this would be the place to do it. ugh. greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-22 9:26 ` Greg KH @ 2018-05-22 16:32 ` Andi Kleen 2018-05-23 14:15 ` Jon Masters 1 sibling, 0 replies; 41+ messages in thread From: Andi Kleen @ 2018-05-22 16:32 UTC (permalink / raw) To: speck > If I wanted to Trojan a whole bunch of people that really should know > better, this would be the place to do it. Yes I agree. That looks pretty suspicious. Much easier to trust good old gpg. -Andi ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-22 9:26 ` Greg KH 2018-05-22 16:32 ` Andi Kleen @ 2018-05-23 14:15 ` Jon Masters 1 sibling, 0 replies; 41+ messages in thread From: Jon Masters @ 2018-05-23 14:15 UTC (permalink / raw) To: speck [-- Attachment #1: Type: text/plain, Size: 1602 bytes --] On 05/22/2018 05:26 AM, speck for Greg KH wrote: > On Tue, May 22, 2018 at 10:00:35AM +0200, speck for Peter Zijlstra wrote: >> On Mon, May 21, 2018 at 04:30:27PM -0400, speck for Jon Masters wrote: >>> Let's skip the FUD tho. It's not a "website". It's an open source >>> end-to-end encrypted chat application. >> >> But it is not packaged by any distro afaik, so you basically have to >> trust their webshite to fetch a binary, which is pretty dodgy if you ask >> me. > > You mean you don't trust the "run a random binary from the internet as > root?" instructions they provide you: > https://keybase.io/docs/the_app/install_linux Conversely, encrypted GPG email is so secure. Just last week, I recall reading about how great it is that there are totally no problems. Do I like the "run this binary" instructions? No. But you can also download the source from github and build it. Which of course is totally secure because we're all going to audit every line of the source before we build it, just like people who rebuild Android because that's way more secure than trusting the images they download. Just like how we all audited our email and GPG implementations, as well as IRC clients, and all of the other software we're running, completely. So anyway, the above aside, I get it. The companies involved were willing to use Keybase (which they suggested), so it was better than the alternative of having no communications channel. There's a lot we can learn collectively as an industry :) Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 16:46 ` [MODERATED] Date/Time? Greg KH 2018-05-21 17:12 ` Konrad Rzeszutek Wilk @ 2018-05-21 17:22 ` Jon Masters 2018-05-21 18:56 ` Date/Time? Thomas Gleixner 2018-05-21 17:31 ` Jon Masters 2018-05-21 18:53 ` Date/Time? Thomas Gleixner 3 siblings, 1 reply; 41+ messages in thread From: Jon Masters @ 2018-05-21 17:22 UTC (permalink / raw) To: speck [-- Attachment #1: Type: text/plain, Size: 2620 bytes --] 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 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. > > 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 older > kernels then. The kernel patches are useless without firmware updates > and I don't know what the state of them are. They're on the keybase channel and have been receiving all of the updated patches. I also specifically sent them a copy previously. > They also complained that they can not finalize their patches as they do > not know what we agreed on for the prctl() interface. Which sucks as > that was hashed out here weeks ago. Nah. As Konrad says, several folk from Arm are on keybase. They also could have pinged us at any time if this was blocking progress. I know resources are tight and committed, but since none of us were pinged, I'm calling BS on that. I've also not been given even an early draft, nor know anyone who has, even though I asked their kernel lead working on this for a copy. I've made my peace with where we are today, sadly. > Another proof of how when we are not "allowed" to talk to the right > people, Linux users suffer. That is not ok. One of the problems does seem to be that we didn't have a dedicated list for v4 earlier. I think it's important to tackle that next time around. Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Date/Time? 2018-05-21 17:22 ` Jon Masters @ 2018-05-21 18:56 ` Thomas Gleixner 2018-05-21 19:16 ` [MODERATED] Date/Time? Jon Masters 0 siblings, 1 reply; 41+ messages in thread From: Thomas Gleixner @ 2018-05-21 18:56 UTC (permalink / raw) To: speck On Mon, 21 May 2018, speck for Jon Masters wrote: > One of the problems does seem to be that we didn't have a dedicated list > for v4 earlier. I think it's important to tackle that next time around. Crap. What's important is that _WE_ can decide and act on our own without having to ask Intel about every fart. Thanks, tglx ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 18:56 ` Date/Time? Thomas Gleixner @ 2018-05-21 19:16 ` Jon Masters 2018-05-21 20:43 ` Greg KH 0 siblings, 1 reply; 41+ messages in thread From: Jon Masters @ 2018-05-21 19:16 UTC (permalink / raw) To: speck [-- Attachment #1: Type: text/plain, Size: 1097 bytes --] On 05/21/2018 02:56 PM, speck for Thomas Gleixner wrote: > On Mon, 21 May 2018, speck for Jon Masters wrote: >> One of the problems does seem to be that we didn't have a dedicated list >> for v4 earlier. I think it's important to tackle that next time around. > > Crap. What's important is that _WE_ can decide and act on our own without > having to ask Intel about every fart. Sure. My point is Intel didn't own v4. GPZ own that one. Intel just took point in doing disclosures to various folks once again. I actually consider what they are trying to do to be quite noble in intention, but (as I have said to Intel's execs with all due intended respect) it's not their place to do this for the whole industry. And it's important to understand the separation between v4 and any other past/future issue. This is why we need a better framework (and some folks are working on something) for joint industry issues that removes single vendors from owning architectural embargoes that impact multiple others. Jon. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 19:16 ` [MODERATED] Date/Time? Jon Masters @ 2018-05-21 20:43 ` Greg KH 0 siblings, 0 replies; 41+ messages in thread From: Greg KH @ 2018-05-21 20:43 UTC (permalink / raw) To: speck On Mon, May 21, 2018 at 03:16:56PM -0400, speck for Jon Masters wrote: > > This is why we need a better framework (and some folks are working on > something) for joint industry issues that removes single vendors from > owning architectural embargoes that impact multiple others. Might I ask who those "some folks" are? I've been talking to a few groups about this recently, CERT included (it's actually their mandate to be the ones to do this, but well...) We should take this off-list... thanks, greg k-h ^ permalink raw reply [flat|nested] 41+ messages in thread
* [MODERATED] Re: Date/Time? 2018-05-21 16:46 ` [MODERATED] Date/Time? Greg KH 2018-05-21 17:12 ` Konrad Rzeszutek Wilk 2018-05-21 17:22 ` Jon Masters @ 2018-05-21 17:31 ` Jon Masters 2018-05-21 18:53 ` Date/Time? Thomas Gleixner 3 siblings, 0 replies; 41+ messages in thread From: Jon Masters @ 2018-05-21 17:31 UTC (permalink / raw) To: speck [-- Attachment #1: Type: text/plain, Size: 2581 bytes --] 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 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. > > 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 older > 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. -- Computer Architect | Sent from my Fedora powered laptop ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Date/Time? 2018-05-21 16:46 ` [MODERATED] Date/Time? Greg KH ` (2 preceding siblings ...) 2018-05-21 17:31 ` Jon Masters @ 2018-05-21 18:53 ` Thomas Gleixner 3 siblings, 0 replies; 41+ messages in thread From: Thomas Gleixner @ 2018-05-21 18:53 UTC (permalink / raw) To: speck On Mon, 21 May 2018, 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 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. > > 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 older > kernels then. The kernel patches are useless without firmware updates > and I don't know what the state of them are. > > They also complained that they can not finalize their patches as they do > not know what we agreed on for the prctl() interface. Which sucks as > that was hashed out here weeks ago. That's odd as I gave them access to the patches on May 9th... Thanks, tglx ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2018-05-23 14:15 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-19 17:26 [MODERATED] Date/Time? Greg KH 2018-05-19 17:51 ` [MODERATED] Date/Time? Borislav Petkov 2018-05-19 18:45 ` Linus Torvalds 2018-05-19 19:07 ` [MODERATED] " Borislav Petkov 2018-05-19 19:48 ` Linus Torvalds 2018-05-19 20:22 ` [MODERATED] " Borislav Petkov 2018-05-20 20:58 ` Jon Masters 2018-05-19 18:21 ` David Woodhouse 2018-05-19 19:05 ` Greg KH 2018-05-20 19:23 ` David Woodhouse 2018-05-20 23:01 ` David Woodhouse 2018-05-21 8:35 ` Greg KH 2018-05-20 17:45 ` Jiri Kosina 2018-05-20 18:19 ` Greg KH 2018-05-20 18:35 ` Borislav Petkov 2018-05-20 19:57 ` Greg KH 2018-05-20 18:36 ` Linus Torvalds 2018-05-20 18:48 ` Jiri Kosina 2018-05-20 20:59 ` Jon Masters 2018-05-20 21:09 ` Jiri Kosina 2018-05-21 6:11 ` Greg KH 2018-05-20 21:48 ` Linus Torvalds 2018-05-20 21:56 ` David Woodhouse 2018-05-21 6:16 ` Greg KH 2018-05-21 7:18 ` David Woodhouse 2018-05-21 15:23 ` Date/Time? Thomas Gleixner 2018-05-21 16:46 ` [MODERATED] Date/Time? Greg KH 2018-05-21 17:12 ` Konrad Rzeszutek Wilk 2018-05-21 19:42 ` Greg KH 2018-05-21 19:48 ` Jiri Kosina 2018-05-21 20:30 ` Jon Masters 2018-05-22 8:00 ` Peter Zijlstra 2018-05-22 9:26 ` Greg KH 2018-05-22 16:32 ` Andi Kleen 2018-05-23 14:15 ` Jon Masters 2018-05-21 17:22 ` Jon Masters 2018-05-21 18:56 ` Date/Time? Thomas Gleixner 2018-05-21 19:16 ` [MODERATED] Date/Time? Jon Masters 2018-05-21 20:43 ` Greg KH 2018-05-21 17:31 ` Jon Masters 2018-05-21 18:53 ` Date/Time? Thomas Gleixner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.