As most of you probably know, new CPU bugs have just been found (1 affecting mostly Intel, 1 affecting Intel + AMD; both potentially affecting phones). I wouldn't mind a MUUG discussion about this. News on the net seems to be pretty low-caliber. Some are better than others. https://spectreattack.com/ seems to be good... but I wouldn't hit that site without a JS blocker. Apparently (could be a myth) these bugs can be triggered by JS in a web page!!! CVE/NVD doesn't seem to have ratings for this yet (still "reserved"). The good news:
From what I read, it's a read-only attack, apparently they can dump your entire RAM without root access. Not great, but better than a RW attack!
KPTI/Kaiser/Meltdown appears to all reference the same thing. Intel only (so far... maybe add ARM), definitely not AMD (so far). Fix can't be done in microcode or firmware. So it'll be patched in kernels (all OS's). OK, great, who cares. But... the patch causes 5-30% performance hit across the board; the more syscalls the program makes, the worse your hit. Fun. The fix is basically move kernel page tables out of RAM when executing user code. Then swap it back in. Joy. Hmmm, by coincidence, Intel's very latest CPUs (unsure on definition of "latest") are rumoured to have an instruction to make this less painful... hmmmmmmm. Spectre seems to be more of a mystery. Apparently it allows progs to read other prog's memory, but not kernel RAM. And no OS fix planned yet? Affects all CPUs with out-of-order exec, which is basically everything in the last, what, 15 years? This one worries me more. However, they say it's harder to implement the hack, so maybe it'll turn out to be a red herring in reality. If it's as scary as some make it sound, we could be seriouly fskc'd because there isn't a syscall boundary to easily insert a nice page table swap into. Going back to my university days and my hardware architecture classes, I find the technical side of this to be fascinating. It looks like they are preying upon weaknesses in CPU handling of speculative loads, indirect addressing, and long pipelines. The fact that the CPUs weren't properly designed to not allow such insane access is quite shocking to me. Pipelines are supposed to be thrown away after an incorrect guess. Nothing should be leaking. Saying "we did it for performance reasons" is quite lame. If anyone finds some good mid- / mid-high-level technical explanations of the on-chip flaws, please post links. It'll be interesting to see what the next gen(s) of CPUs do to specifically address this. Given design/fab lifecycles it could be years before new CPUs have this fixed. Surely pipelines / OOE aren't going away. Heck, even RISC wouldn't have saved us, as they are monga pipeline dependent. My hunch is PPC is Spectre vulnerable, but it'll be interesting to find out more. The above is all just my take on things after binge-reading about 8 different articles on it. If I'm wrong on something, please correct me. Supposedly Linus has ranted on it already, but I can't find it anywhere, so if you have a link to a Linus rant, please share. In the meantime, get ready for all your newer/supported devices to get 5%+ slower, and all your older devices to get p0wned. Me, I'm going to jump on that new ECC workstation I've been eyeing... I won't be able to handle any slowdown on my current, ancient box. Final thought... why didn't anyone figure this flaw out earlier in the last 10 years it existed? Wonder who was exploiting it this whole time... wonder how long Intel knew (not the "official" version). Anyone laying bets on class-actions and/or CPU recalls? Not sure Intel could make enough CPUs (or afford it) to replace every CPU it sold in the last 10 years.
FYI, Fedora has just released the latest kernel that has initial mitigation for Meltdown. I'm sure other distros are doing likewise. It'll be interesting to see the performance hits we all take on this. Of course you'll have to reboot for the update to take effect. I suspect we'll see rapidfire releases of kernels for the next few weeks... P.S. Alan Cox has stated that the Spectre-type flaw (I think) could be triggered with a JS attack, causing the browser to leak sensitive data outside the sandbox to malicious JS / websites. Proving once again we all need NoScript or equivalent.
I just updated our Scientific Linux systems, which means the RHEL updates are out too, and presumably CentOS updates are too or will be shortly. These updates included firmware/microcode packages, which I'm assuming are loaded on reboot as well. Some of the reports I read suggested that you'd need to reflash your BIOS/UEFI firmware once the PC manufacturers release these updates. Are those reports in error, confusing the two types of firmware, or are we going to have to hunt down PC or mobo-specific firmware updates for this whole debacle too? On 2018-01-04 17:00, Trevor Cordes wrote:
FYI, Fedora has just released the latest kernel that has initial mitigation for Meltdown. I'm sure other distros are doing likewise. It'll be interesting to see the performance hits we all take on this. Of course you'll have to reboot for the update to take effect. I suspect we'll see rapidfire releases of kernels for the next few weeks...
P.S. Alan Cox has stated that the Spectre-type flaw (I think) could be triggered with a JS attack, causing the browser to leak sensitive data outside the sandbox to malicious JS / websites. Proving once again we all need NoScript or equivalent.
-- Gilles R. Detillieux E-mail: <grdetil@scrc.umanitoba.ca> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. of Physiology and Pathophysiology, Faculty of Health Sciences, Univ. of Manitoba Winnipeg, MB R3E 0J9 (Canada)
On 2018-01-04 Gilles Detillieux wrote:
I just updated our Scientific Linux systems, which means the RHEL updates are out too, and presumably CentOS updates are too or will be shortly. These updates included firmware/microcode packages, which
Interesting on the fw/microcode as what I read indicated this can't be fixed in fw/mc. Though perhaps fw/mc changes could help in some way, in tandem with the OS.
I'm assuming are loaded on reboot as well. Some of the reports I read suggested that you'd need to reflash your BIOS/UEFI firmware once the PC manufacturers release these updates. Are those reports in error, confusing the two types of firmware, or are we going to have to hunt down PC or mobo-specific firmware updates for this whole debacle too?
Again, from what I read, this won't be a fw thing, so I don't think we'll see the above scenario. If we do -- if fix=fw+os -- then we're in for a world of hurt because most mfr's stop updating fw after their cycle, usually max of 3 years, some much less. That would leave a whole slew of mobos unfixable. Good way for the industry to force a rapid upgrade cycle!!! That might really get Intel in trouble, though... $$$ lawsuits. Of course, it's early days, so I could be way offbase, and even if I'm correct now, my info may be wrong in a few days/weeks.
I don't know what's being fixed, but there are already microcode updates available for some Haswell Xeon E5 chips, according to OVH's (probably the 4th or 5th largest consumer of them) CEO on Twitter. In same tweet, said older chips (no idea how old) would get updates within weeks. YMMV. -Adam On January 4, 2018 6:02:50 PM CST, Trevor Cordes <trevor@tecnopolis.ca> wrote:
On 2018-01-04 Gilles Detillieux wrote:
I just updated our Scientific Linux systems, which means the RHEL updates are out too, and presumably CentOS updates are too or will be
shortly. These updates included firmware/microcode packages, which
Interesting on the fw/microcode as what I read indicated this can't be fixed in fw/mc. Though perhaps fw/mc changes could help in some way, in tandem with the OS.
I'm assuming are loaded on reboot as well. Some of the reports I read
suggested that you'd need to reflash your BIOS/UEFI firmware once the PC manufacturers release these updates. Are those reports in error, confusing the two types of firmware, or are we going to have to hunt down PC or mobo-specific firmware updates for this whole debacle too?
Again, from what I read, this won't be a fw thing, so I don't think we'll see the above scenario. If we do -- if fix=fw+os -- then we're in for a world of hurt because most mfr's stop updating fw after their cycle, usually max of 3 years, some much less. That would leave a whole slew of mobos unfixable. Good way for the industry to force a rapid upgrade cycle!!! That might really get Intel in trouble, though... $$$ lawsuits.
Of course, it's early days, so I could be way offbase, and even if I'm correct now, my info may be wrong in a few days/weeks. _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 2018-01-04 Adam Thompson wrote:
I don't know what's being fixed, but there are already microcode updates available for some Haswell Xeon E5 chips, according to OVH's (probably the 4th or 5th largest consumer of them) CEO on Twitter. In same tweet, said older chips (no idea how old) would get updates within weeks. YMMV. -Adam
Oh ya, that's right... as I said in my original post, the very very latest Intel chips have new instructions that can mitigate this. Perhaps they are changing microcode to auto-run the new instruction when it would be prudent. Not sure how they can do that fix for older chips without the instruction though. News is so sparse, poor quality, and often conflicting at the mo. We'll see how the dust settles. Everyone seems to be focusing on Meltdown (kernel RAM) but nothing I'm looking at seems to solve Spectre (user RAM). Man your JS blockers! That link from Linus has a good technical write up, with code: https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with... Haven't waded through it all yet, but I'm eager to toy with the C code and see what I can see on my own box.
Latest news: - Reading the tech docs by Horn I find it incredibly interesting that the "Spectre variant #1" problem is basically the same thing as a statistical timing on password validation algorithms, much like PHP faced when it decided to write its own constant-time password handling routines. So this really isn't a pipeline leak flaw per se, it's using timing of a read to determine if an out-of-bounds read was cached or not, to determine inaccessible memory a bit at a time. Most of the non-tech articles make it sound like Intel made some horrible buggy design choice. But just as no one thought about password compare timing attacks 20 years ago, so no one thought about timing attacks on the cache subsystem. I certainly didn't. These attack vectors are getting insanely smart, and now that the timing genie is out of the bottle I expect timing flaws to pop up everywhere. - Looks like Intel is releasing firmware (and patches) that addresses the two (actually, three) issues. Not sure how much it actually addresses, or how it's doing it. Regardless, looks like Intel's fixes will trigger the 5-30% performance hit. They claim future updates will "mitigate that impact" through "improvement" (read: optimization). I, for one, am not buying the feel-good press releases that make it sound like one fw update and you can ignore this issue. What Intel is doing/saying directly contradicts numerous other "firmware can't fix it" reports elsewhere. - Intel is only releasing updates for products "introduced within the past five years", so far. My take is you won't see much work on stuff older than that. So there goes a ton of systems I manage -- my M.O. is to squeeze extra life out of good ECC boxes. Also, if all this new fw is mobo-targeted, this won't help the vast majority of the world who has Taiwan-Inc 3rd party mobos. They will have to release new fw, and my guess is Tier-2 Taiwan-Inc aren't going to go back 5 years like Intel is. - Will fw fixes cause OS devs to not double-fix the same problems? Methinks Linus et al will not tolerate the hw-vendor mantra of "screw those with 5+ year old hw". A best-case scenario would be OS vendors completely working around these flaws (if possible) and Intel (et al) working to implement complementary microcode tweaks that reduce the performance impact. - Apparently Google has a "chip-level patch" (i.e. microcode?) that vastly reduces the performance hit. They call it "Retpoline". Not sure how that's going to fit into the equation.
An interesting read... https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre... It takes a while to get to the point of why the RPi isn't vulnerable, but along the way, it nicely illustrates (in fairly accessible language) the concepts involved in the exploits. -- Manitoba UNIX User Group E-mail: <gedetil@muug.ca> c/o Gilbert E. Detillieux Web: http://muug.ca/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609
A bit dated now, but I just came across this... https://xkcd.com/1938/ "Phantom trolleys armed with hammers"... Sounds scary... or perhaps just a good band name. -- Manitoba UNIX User Group E-mail: <gedetil@muug.ca> c/o Gilbert E. Detillieux Web: http://muug.ca/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609
All I know is. Both are a very slim chance of being effected. It is not some skit flaw. It takes a lot of damn luck and skill. Both had been known for years under googles bounty project. Every device with speculative programming is effected. If you want more information while listening to a podcast watch Linus Tech Tips WAN show about it. So if you are truly worried about getting effected. Get your Motorola Razors and P3s out of storage and put lubuntu on that old IDE HDD On Jan 22, 2018 9:54 AM, "Gilbert E. Detillieux" <gedetil@cs.umanitoba.ca> wrote:
A bit dated now, but I just came across this...
"Phantom trolleys armed with hammers"... Sounds scary... or perhaps just a good band name.
-- Manitoba UNIX User Group E-mail: <gedetil@muug.ca> c/o Gilbert E. Detillieux Web: http://muug.ca/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609 _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Also I've tested some "Linux Spector Tests" that make it seem that your pc is safe but in the background it opens the easiest back door for the creator to get into your system. So test them in vms before you run them on your daily driver os On Jan 22, 2018 10:01 AM, "Bitters" <bittercake2329@gmail.com> wrote:
All I know is. Both are a very slim chance of being effected. It is not some skit flaw. It takes a lot of damn luck and skill.
Both had been known for years under googles bounty project.
Every device with speculative programming is effected.
If you want more information while listening to a podcast watch Linus Tech Tips WAN show about it.
So if you are truly worried about getting effected.
Get your Motorola Razors and P3s out of storage and put lubuntu on that old IDE HDD
On Jan 22, 2018 9:54 AM, "Gilbert E. Detillieux" <gedetil@cs.umanitoba.ca> wrote:
A bit dated now, but I just came across this...
"Phantom trolleys armed with hammers"... Sounds scary... or perhaps just a good band name.
-- Manitoba UNIX User Group E-mail: <gedetil@muug.ca> c/o Gilbert E. Detillieux Web: http://muug.ca/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609 _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
participants (5)
-
Adam Thompson -
Bitters -
Gilbert E. Detillieux -
Gilles Detillieux -
Trevor Cordes