Personal computing discussed

Moderators: Flying Fox, morphine

  • 1
  • 2
  • 3
  • 4
  • 5
  • 8
 
bhtooefr
Silver subscriber
Lord High Gerbil
Posts: 8191
Joined: Mon Feb 16, 2004 11:20 am
Location: Newark, OH
Contact:

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 7:49 am

Shift that a bit - Haswell/Broadwell and Skylake/Kaby Lake/Coffee Lake should have moderate impact.

Westmere should have similar (higher) impact to Ivy (and Sandy) Bridge, because it has PCID.

Nehalem and earlier should have very high impact, not having PCID.

Also, I've seen a claim (but it was on Hacker News, so take that with a snowplow full of salt) that this issue existed in Pentium III. If that's true, I suspect it also exists in Pentium II, and likely Pentium Pro... and if it goes back that far, it probably goes forward to literally everything except Quark (can't speculatively execute outside of your permissions if you can't speculatively execute), original Xeon Phi (possible for it to be affected, but it's original Pentium-based and therefore unrelated to the P6 lineage - and without out of order execution, and with a short and narrow pipeline, the effect is harder to exploit if it's even there), NetBurst (possible for it to be affected, but it was a clean-sheet design), and Atom and Atom-derived designs (ditto, with the caveat that Bonnell doesn't have out of order execution, making it harder to exploit if it is affected, but Silvermont and Goldmont added that).

Edit: Also, looks like the Atom family never got PCID, so if it's affected (or if it gets PTI without being affected - on Linux, this looks like it'll be the case by default unless PTI is forced off at boot time, or AMD submitted a patch to disable the PTI default on their CPUs but that won't help an Atom), the performance hit is going to be colossal.
Image
 
ColeLT1
Silver subscriber
Gerbil First Class
Topic Author
Posts: 146
Joined: Thu Mar 13, 2008 3:40 pm
Location: Jackson, MS

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 8:40 am

Update, 10:56 PM - 1/2/18 - As it turns out, apparently the Linux patch that is being rolled out is for ALL x86 processors including AMD, and the Linux mainline kernel will treat AMD processors as insecure as well. As a result, AMD CPUs will feel a performance hit as well, though the bug only technically affects Intel CPUs and AMD recommends specifically not to enable the patch for Linux. How Microsoft specifically will address the issue with the Windows operating system remains unclear until the company's formal Patch Tuesday update is made known, hopefully soon.


https://hothardware.com/news/intel-cpu- ... dows-macos

Ouch

I bet this has little effect on my gaming machines, but my (work) enterprise vmfarm is going to take a hit, all Xeon e5 v1-v3.
 
rudimentary_lathe
Gerbil In Training
Posts: 7
Joined: Wed Feb 17, 2016 9:25 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 10:16 am

Blech. This looks like it could have a large impact on servers/VM farms. Someone really screwed the pooch at Intel if this can't be fixed via microcode.
 
Prestige Worldwide
Gerbil Elite
Posts: 738
Joined: Mon Nov 09, 2009 10:57 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 10:24 am

As a new 8700k user, I'm hoping the ~0% change in gaming performance in linux is also the case in windows.

Otherwise, I'mma gonna be sad :(
i7-8700k, Custom Water Loop | ASRock Fatal1ty Gaming K6 | 16GB DDR4 3200 CL16
GTX 1080 | BenQ 24" 120Hz | 2x Samsung 840 250GB | 2x2TB HDKPC09 | Win 10 Pro x64
X-Fi Titanium Fatal1ty Pro | Sennheiser HD555 | Seasonic SSR-850FX | Fractal Arc Midi R2
 
fyo
Gerbil
Posts: 49
Joined: Mon Apr 21, 2003 5:43 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 10:24 am

rudimentary_lathe wrote:
Blech. This looks like it could have a large impact on servers/VM farms. Someone really screwed the pooch at Intel if this can't be fixed via microcode.


It can't. The positive spin for Intel is that the fix, at least as implemented in Linux, also prevents certain other (much less severe) attacks on kernel address space layout randomization. So, sure, there's a bug, but the fix also helps with other stuff, so Intel could argue that they are safer. They could also pressure Microsoft to include the patch for AMD processors as well, with the same line of reasoning.
 
K-L-Waster
Gerbil Team Leader
Posts: 243
Joined: Thu Feb 12, 2015 8:10 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 10:40 am

Prestige Worldwide wrote:
As a new 8700k user, I'm hoping the ~0% change in gaming performance in linux is also the case in windows.

Otherwise, I'mma gonna be sad :(


Same boat here. (Sounds like a nasty variant on our "Fish you should have waited" meme....)
Main System: i7-8700K, ASUS ROG STRIX Z370-E, 16 GB DDR4 3200 RAM, MSI GTX 1080 TI, 1 TB CRUCIAL MX500, Corsair 550D

HTPC: I5-4460, ASUS H97M-E, 8 GB RAM, GTX 970, CRUCIAL 256GB MX100, SILVERSTONE GD09B
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1773
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 10:41 am

There's a bunch of confusion about what PTI is about. It is a fix for the speculative instruction with ring-level escalation bug that is being talked about here, but it is not only a bug fix for that particular bug. It does provide additional security even beyond this bug at the potential cost of performance in some instances. Frankly, the long-term solution is for the processors to enforce page table isolation between privilege levels (e.g. between userspace & kernel and even between kernel & hypervisor) at the hardware level itself. Most of the danger of this bug occurs in virtualized environments.

If you look at some of the recent kernel work from November you'll see similar patches being proposed for ARM64, which is a completely different architecture: https://lwn.net/Articles/740393/
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
K-L-Waster
Gerbil Team Leader
Posts: 243
Joined: Thu Feb 12, 2015 8:10 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 10:43 am

ColeLT1 wrote:
Update, 10:56 PM - 1/2/18 - As it turns out, apparently the Linux patch that is being rolled out is for ALL x86 processors including AMD, and the Linux mainline kernel will treat AMD processors as insecure as well. As a result, AMD CPUs will feel a performance hit as well, though the bug only technically affects Intel CPUs and AMD recommends specifically not to enable the patch for Linux. How Microsoft specifically will address the issue with the Windows operating system remains unclear until the company's formal Patch Tuesday update is made known, hopefully soon.


https://hothardware.com/news/intel-cpu- ... dows-macos


In a way, this makes sense. First make sure everything is locked down and secure -- if in the process you also detain innocent civilians, better that than letting the bad guys through. Hopefully for the sake of AMD users they dial it back later.
Main System: i7-8700K, ASUS ROG STRIX Z370-E, 16 GB DDR4 3200 RAM, MSI GTX 1080 TI, 1 TB CRUCIAL MX500, Corsair 550D

HTPC: I5-4460, ASUS H97M-E, 8 GB RAM, GTX 970, CRUCIAL 256GB MX100, SILVERSTONE GD09B
 
Krogoth
Gerbil Elder
Posts: 5401
Joined: Tue Apr 15, 2003 3:20 pm
Location: somewhere on Core Prime
Contact:

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 11:09 am

It is quite possible that is a flaw from the x86 ISA itself.
Ivy Bridge i5-3570K@4.0Ghz, Gigabyte Z77X-UD3H, 2x4GiB of PC3-12800, Sapphire RX Vega 64, Corsair CX-600 and Fractal Refined R4 (W). Kentsfield Q6600@3Ghz, HD 4850 2x2GiB PC2-6400, Gigabyte EP45-DS4P, OCZ Modstream 700W, and PC-7B.
 
drfish
Gold subscriber
Gerbil Elder
Posts: 5186
Joined: Wed Jan 22, 2003 7:53 pm
Location: Zeeland, MI

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 11:11 am

K-L-Waster wrote:
Prestige Worldwide wrote:
As a new 8700k user, I'm hoping the ~0% change in gaming performance in linux is also the case in windows.

Otherwise, I'mma gonna be sad :(


Same boat here. (Sounds like a nasty variant on our "Fish you should have waited" meme....)


:lol:
TR BBQ XV is happening 6/23/18. Don't miss it!
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1773
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 11:12 am

Krogoth wrote:
It is quite possible that is a flaw from the x86 ISA itself.


Well, if you had read the technical discussion you would know that's completely wrong.
And it would be rather strange for ARM64 to have similar patches posted in November. Which I linked above.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10848
Joined: Tue Aug 27, 2002 6:35 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 11:58 am

Krogoth wrote:
It is quite possible that is a flaw from the x86 ISA itself.


No. It has nothing to do with an infoleak from the architectural registers outright, but rather that clearly someone has finally figured out a way to detect the behind-the-scenes micro-architectural state of the processor due to Intel's implementation in way that constitutes an infoleak. That's the part that is missing, and has been embargoed until at least Jan. 10. It may even be more serious than a guaranteed infoleak, but a *guaranteed* (and microcode-invulnerable) infoleak independent of any ephemeral kernel coding-flaw is serious enough to warrant all this by itself: We can't play the perennial game of infoleak whack-a-mole and just ignore the big Problem as series of ostensibly unrelated smaller problems as we have been.

Spender drives me nuts, but he's been on this horse already (as usual, despite my distaste for him): implementions of UDEREF on AMD64 can do the same thing as all these recent reason-redacted patches. He was even toying around with that specific idea 10 years ago, but before the advent of performance relief in the form (finally!) PCID being added with Westmere(?) such a total solution "wasn't even on the table". He initially did it with segmentation, IIRC.

In any event, he had performance numbers like the ones you see today years ago, maybe even from 2013. I'm not sure when UDEREF had an possible implemention to unmap kernel space entirely, but it's not new even if it's not usually configured that way or ever deployed as such.

---

So, while we don't know the exact form of the exploit, we do know a quite a bit: Researchers earlier this year demonstrated that Intel's Speculation Engine in its latest architectures(or old too, generally not tested) was not side-channel safe. They were able to detect what should be spurious execution pretty fair along the chain, in a way that raised a lot of eyebrows. They could figure out how to mildly influence it as well, they just couldn't figure out how to do or gain anything useful (other than the generic suggestion of how it's yet another source of information/potential flow influence for timing attacks)

Well. It seems that now someone has. More specifically, it would seem that someone has managed to figure how to reliably deduce the contents of kernel memory.
Last edited by Glorious on Wed Jan 03, 2018 12:02 pm, edited 2 times in total.
 
fyo
Gerbil
Posts: 49
Joined: Mon Apr 21, 2003 5:43 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 12:01 pm

chuckula wrote:
Krogoth wrote:
It is quite possible that is a flaw from the x86 ISA itself.


Well, if you had read the technical discussion you would know that's completely wrong.
And it would be rather strange for ARM64 to have similar patches posted in November. Which I linked above.


In fairness, he could be referring to the Intel bug and not the general attack on kernel address space layout randomization. While that wouldn't make the statement correct, it would at least make it a reasonable (but still incorrect) assumption.

The ARM64 patches are the KAISER mitigation patches for ARM, now called PTI (Page Table Isolation), sometimes with a K for Kernel in front - although I must admit I prefer the other suggestion listed on the Linux Kernel Mailing List: Forcefully Unmap Complete Kernel With Interrupt Trampolines, which, while more verbose, is both accurate and has a superior acronym.

It's critical to note that vulnerability to KASLR timing attacks is COMPLETELY different than the Intel bug, which has yet to get a catchy name. Breaking KASLR does nothing in and of itself. It makes it easier to successfully exploit OTHER bugs (mainly overflows). The unnamed Intel bug, on the other hand, leaks contents of (potentially) all data in memory, with no other bugs needed for exploitation.

To confuse matters further, the only FEASIBLE direct attack on KASLR (and the one which promoted the KAISER work to be initiated) requires an Intel processor with TSX.
 
Kougar
Minister of Gerbil Affairs
Posts: 2253
Joined: Tue Dec 02, 2008 2:12 am
Location: Texas

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 12:17 pm

 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10848
Joined: Tue Aug 27, 2002 6:35 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 12:23 pm

fyo wrote:
In fairness, he could be referring to the Intel bug and not the general attack on kernel address space layout randomization. While that wouldn't make the statement correct, it would at least make it a reasonable (but still incorrect) assumption.

The ARM64 patches are the KAISER mitigation patches for ARM, now called PTI (Page Table Isolation), sometimes with a K for Kernel in front - although I must admit I prefer the other suggestion listed on the Linux Kernel Mailing List: Forcefully Unmap Complete Kernel With Interrupt Trampolines, which, while more verbose, is both accurate and has a superior acronym.

It's critical to note that vulnerability to KASLR timing attacks is COMPLETELY different than the Intel bug, which has yet to get a catchy name. Breaking KASLR does nothing in and of itself. It makes it easier to successfully exploit OTHER bugs (mainly overflows). The unnamed Intel bug, on the other hand, leaks contents of (potentially) all data in memory, with no other bugs needed for exploitation.


KAISER is but a practical system for finally deploying the nuclear option of "MY FELLOW USERS, I'M PLEASED TO ANNOUNCE THAT I'VE COMMITTED PATCHES THAT WILL UNMAP KERNEL SPACE FOREVER. WE BEGIN DESTROYING PERFORMANCE IN FIVE MINUTES" that's less ...nuclear? It was a response to how we're not just dealing with infinitely generating software infoleaks, but how, clearly, there are numerous ways to side-channel hardware like the one I just described that we simply have no hope of stopping. Game over man, GAME OVER! Nuke it from orbit, etc... (but it'll be a tactical strike, not strategic MADness, we promise!).

In other words, we have to do it, and here is a way that is 1) realistic and 2) less murderous on performance. It's still not *great* for performance, but these things are relative.

---

So, that said, I don't really follow what you are saying. It all seems very muddled and confused to me, and the only part that I can pick out is that you seem to distinguish between being able to read kernel memory and so forth *outright* (from userspace) and the ability to piece together, by bits and bytes, what the base address is. Yes, those are different things with vastly different consequences that we equally call "infoleaks" (even though, yes, the connotation of infoleak really is of the lesser variety, like parts of pointers etc... It's difficult to state all caveats when dealing with such complexity), but as I'll say next, the practical relevancy of the latter is not immense unless you roll your own:

fyo wrote:
To confuse matters further, the only FEASIBLE direct attack on KASLR (and the one which promoted the KAISER work to be initiated) requires an Intel processor with TSX.


Uh, a feasible direct attack on KASLR (The R standing for Randomization) is literally `uname -a` on a distro-provided binary kernel. Bam. You now know the base address and all entropy is defeated, like magic. :wink:
Last edited by Glorious on Wed Jan 03, 2018 12:27 pm, edited 1 time in total.
 
fyo
Gerbil
Posts: 49
Joined: Mon Apr 21, 2003 5:43 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 12:25 pm

Kougar wrote:
https://twitter.com/brainsmoke/status/948561799875502080


Yeah, that didn't take long.

Some outlets are reporting that proof of concept is now available and referencing this link. While I don't doubt that brainsmoke has written it, there's no indication that it's public. Yet. It's not hard to do now that the cat is so far out of the bag. These patches need to land sooner rather than later, although I doubt Microsoft will rush a fix out before Patch Tuesday.
 
DeadOfKnight
Gerbil Elite
Posts: 699
Joined: Tue May 18, 2010 1:20 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 12:27 pm

chuckula wrote:
For some context about OMG IT'S THE END OF THE WORLD... some synthetic Linux benchmarks showed some hits although the real-world tests like a kernel compile run and x264/FFMPEG encoding were basically unchanged:

https://www.phoronix.com/scan.php?page= ... 6pti&num=1

As for the world of games.... zero change (the post bug-fix even wins by tiny margins in some tests): https://www.phoronix.com/scan.php?page= ... ming-Tests

While this may be true, as a member of this community in particular, you should know that FPS is not a very good metric for comparison of performance in games.
Intel Core i7-5775c, Asus Maximus VII Formula, Win 10 Pro
EVGA GTX 1080, Corsair 2x8GB DDR3-1866, Corsair AX860
Corsair H105, WD Red 4TB x2, Creative X-Fi Titanium HD
Samsung 850 EVO 1TB, ASUS ROG PG348Q, Corsair 450D
 
fyo
Gerbil
Posts: 49
Joined: Mon Apr 21, 2003 5:43 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 12:43 pm

Glorious wrote:
that said, I don't really follow what you are saying. It all seems very muddled and confused to me, and the only part that I can pick out is that you seem to distinguish between being able to read kernel memory and so forth *outright* (from userspace) and the ability to piece together, by bits and bytes, what the base address is. Yes, those are different things with vastly different consequences that we equally call "infoleaks" (even though, yes, the connotation of infoleak really is of the lesser variety, like parts of pointers etc... It's difficult to state all caveats when dealing with such complexity), but as I'll say next, the practical relevancy of the latter is not immense unless you roll your own:


Yes, that's exactly my point. Your point that KASLR isn't relevant in a lot of situations only reinforces how much more serious the Intel bug is compared to the DrK-like attacks on KASLR.

I'm not sure what part you consider muddled, since you apparently understood everything. I merely attempted to point out that there are two different issues at work and that the KAISER/KPTI patches "just happen" to address the bug. It is, as you point out, a rather nuclear option, though.

The reason I felt this distinction was worth pointing out, is that a lot of people are confusing the two issues to the point where one of the authors of the Black Hat DrK paper came out and said the bug was old news (as in covered in their 2016 paper). Now, I've read the original paper (available here) and the Black Hat talk (slides here) just covered the same.
 
Wren
Gerbil
Posts: 80
Joined: Wed Jul 09, 2014 4:15 pm
Location: England

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 12:57 pm

Sorry if I sound stupid but does this affect AMD Zen CPUs? I have heard conflicting reports. Thanks.
Ryzen 7 1800X @ 4.025 GHz | 16GB @ 3200 MHz C14 | MSI B350 PC MATE| Asus Turbo GTX 1070 Ti | Samsung Polaris-thingy M.2 SSD | Samsung 850 PRO 128GB | 3x 1TB HDDs |650W Seasonic G-Series Gold |NZXT H440 |Creative Soundblaster Z
 
Vhalidictes
Gold subscriber
Gerbil Jedi
Posts: 1775
Joined: Fri Jan 07, 2005 2:32 pm
Location: Paragon City, RI

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 1:01 pm

Wren wrote:
Sorry if I sound stupid but does this affect AMD Zen CPUs? I have heard conflicting reports. Thanks.


It doesn't affect Zen.

No one has said whether it affects 'dozer, but then again it's possible no one cares about the Construction Cores. I know I don't.
Last edited by Vhalidictes on Wed Jan 03, 2018 1:01 pm, edited 1 time in total.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1773
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 1:01 pm

Wren wrote:
Sorry if I sound stupid but does this affect AMD Zen CPUs? I have heard conflicting reports. Thanks.


According to AMD the same bug that affects Intel chips does not affect Zen because Zen does not perform the same type of privilege-elevated speculative instructions.
So this particular bug does not affect Zen.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
End User
Gold subscriber
Minister of Gerbil Affairs
Posts: 2710
Joined: Fri Apr 16, 2004 6:47 pm
Location: Upper Canada

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 1:01 pm

macOS had a fix for the bug in 10.13.2. No mention of how much of a performance hit it took.
"Straight roads are for fast cars, turns are for fast drivers" - Colin McRae

"If you drive an auto or a dual-clutch you should hang your head in shame." - EU
 
Ninjitsu
Gerbil Team Leader
Posts: 217
Joined: Thu Feb 20, 2014 3:46 am

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 1:08 pm

http://www.tomshardware.com/news/intel- ... 36208.html

They seem to be suggesting that there's too much conflicting information at the moment, and that 30% perf hits are overstated.
 
just brew it!
Gold subscriber
Administrator
Posts: 51036
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 1:41 pm

Vhalidictes wrote:
Wren wrote:
Sorry if I sound stupid but does this affect AMD Zen CPUs? I have heard conflicting reports. Thanks.

It doesn't affect Zen.

No one has said whether it affects 'dozer, but then again it's possible no one cares about the Construction Cores. I know I don't.

I still run an FX-8350, but it sounds like for typical desktop use this bug is low risk, and in any case the performance hit of the fix will likely be small. So meh.

I suppose anyone who bought Opterons of that generation for datacenter use might care. But all 15 of those users probably have plans to replace them with something more modern (if they haven't already done so).
Nostalgia isn't what it used to be.
 
K-L-Waster
Gerbil Team Leader
Posts: 243
Joined: Thu Feb 12, 2015 8:10 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 1:44 pm

chuckula wrote:
Wren wrote:
Sorry if I sound stupid but does this affect AMD Zen CPUs? I have heard conflicting reports. Thanks.


According to AMD the same bug that affects Intel chips does not affect Zen because Zen does not perform the same type of privilege-elevated speculative instructions.
So this particular bug does not affect Zen.


Having said that, it does appear that at least some of the patches so far are not differentiating based on chip type, so even if Zen doesn't have the vulnerability you may end up getting the performance hit from the fix.
Main System: i7-8700K, ASUS ROG STRIX Z370-E, 16 GB DDR4 3200 RAM, MSI GTX 1080 TI, 1 TB CRUCIAL MX500, Corsair 550D

HTPC: I5-4460, ASUS H97M-E, 8 GB RAM, GTX 970, CRUCIAL 256GB MX100, SILVERSTONE GD09B
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1773
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 1:44 pm

just brew it! wrote:
Vhalidictes wrote:
Wren wrote:
Sorry if I sound stupid but does this affect AMD Zen CPUs? I have heard conflicting reports. Thanks.

It doesn't affect Zen.

No one has said whether it affects 'dozer, but then again it's possible no one cares about the Construction Cores. I know I don't.

I still run an FX-8350, but it sounds like for typical desktop use this bug is low risk, and in any case the performance hit of the fix will likely be small. So meh.

I suppose anyone who bought Opterons of that generation for datacenter use might care. But all 15 of those users probably have plans to replace them with something more modern (if they haven't already done so).


If Zen doesn't implement the same type of speculative instruction execution feature that caused the bug in Intel chips then something tells me Bulldozer/Piledriver parts are highly unlikely to share the same bug.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
Glorious
Gold subscriber
Grand Admiral Gerbil
Posts: 10848
Joined: Tue Aug 27, 2002 6:35 pm

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 1:47 pm

fyo wrote:
Yes, that's exactly my point. Your point that KASLR isn't relevant in a lot of situations only reinforces how much more serious the Intel bug is compared to the DrK-like attacks on KASLR.


Then why did you say:
fyo wrote:
the only FEASIBLE direct attack on KASLR (and the one which promoted the KAISER work to be initiated) requires an Intel processor with TSX.


This is not even remotely true.

Let's get back to basics:

The randomization is just an attempt to hide the map: For a spy, it doesn't get you over the border or tell you where the enemy actually is. But, of course, to a spy, a map is incredibly useful: should you manage to get across the border, would you rather randomly choose coordinates and potentially wander around deserts, swamps or tundra, or would you like to have a list of interesting places like military bases, air strips, and transportation hubs to visit?

The first problem we have in regards to randomization, the map, is that every time we shuffle our troops around or change our infrastructure (i.e. develop the kernel and release new versions), we leave clues that enemy can discover to figure out that map. We keep hoping that we'll stop leaving obvious clues, but we're not so good at that.

The second problem is that, inherent to topographical landscape of our country, the enemy can hear the echos of what we do through a variety of means and deduce the map that way (i.e. hardware side-channels). That's stupendous expensive to modify (we have change the valleys & mountains), will take a lot of time (can't move that much earth overnight) and we're not entirely sure what configurations of land features will prevent the hearing of those echoes, we just know about some rather obvious ones. In fact, it's likely that different configurations would impose productivity & transportation delays: It seems that easiest way to stop echoes means putting mountains & rivers in inconvenient places (i.e. the clearest way to stop covert-channels into speculative activity is to not fully do that speculation--since execution, however spurious, has a cost, it is almost certainly being done [and thus potentially detectable] because stopping it has even greater power/performance implications. This is not trivial.)

The new problem is that now they've got a spy satellite that can stream video in real-time: They don't just see the map however we change it, but they also see everything on it. They know where all our planes, troops and ships are. Our only hope is to build an gigantic box around our country, which won't just hide the map, but everything on it. That's just, you know, really inconvenient.

---

This was all known. And it's not just the TSX attack you alluded to in the previous post (which is the DrK thing you specify now, right?), it's a bunch of things: The Introduction in the KAISER paper lists *THREE* different *HARDWARE ATTACKS* (among other things) that reveal address information, and since they are hardware, the jig's up chaps. I mean, it wasn't looking good before, but at least we could put our thumb in the dyke and hum really loud.

---

Anyway, yes, "the Intel bug" is indeed much, much more serious, as you say now, but what you were saying before completely confused me because it's entirely not true. The situations are all-related too, because once people start coming out the woodwork with multiple methods to leak info about addresses in kernel-space via these kinds of micro-architecture side-channel detections, people were openly saying stuff like "It's good that I couldn't manage to actually read kernel memory BUT you know, I got kinda close?" :o

I mean, this happened fast: I first remember people airing about this possibility vaguely like a year ago, probably not even two.

fyo wrote:
I'm not sure what part you consider muddled, since you apparently understood everything. I merely attempted to point out that there are two different issues at work and that the KAISER/KPTI patches "just happen" to address the bug. It is, as you point out, a rather nuclear option, though.


Uh, no?

If what is embargoed is an eminently practicable arbitrary read of any kernel address, as it increasingly appears to be, this didn't just *happen* to address this situation with the Intel micro-architecture--it is the only solution to it.

My point was that KAISER (which, again, is SIMPLY A PRACTICALLY-MINDED IMPLEMENTATION of a PRE-EXISTING EXTREME IDEA)was in the works, and that spender of grsecurity (to my knowledge) first suggested it *TEN YEARS AGO* because it was clear where this was going: We're gonna have to unmap kernel space dudes.

KAISER isn't the idea, it's just an idea about how to make that idea hurt less because we're gonna have to do it now. It's simply a method of doing something known to be very bad less badly because we're run out of other options.

It's not *new*, and it's not happenstance or whatever: I've talked this kind of problem HERE ten years ago myself:

viewtopic.php?p=607096#p607096

Glorious wrote:
That has nothing to do with the fact x86 doesn't have enough registers, there isn't an ASID for TLB entries, poor virtualization compliance etc...


viewtopic.php?p=741508#p741508

Glorious wrote:
If the kernel had a different virtual address space that would mean that we'd have to do one of those TLB-flushing context switches each and every time you did a syscall. It would murder performance. This is why Windows XP (and linux, and Mac OS etc...) does a mode transition for syscalls instead of a context switch. You only switch between VASes when you switch between processes! It's the only sane way to code an OS on x86.


fyo wrote:
The reason I felt this distinction was worth pointing out, is that a lot of people are confusing the two issues to the point where one of the authors of the Black Hat DrK paper came out and said the bug was old news (as in covered in their 2016 paper). Now, I've read the original paper (available here) and the Black Hat talk (slides here) just covered the same.


Well, let's be clear then, clearer than you are because you're saying this is two bugs: the DrK one and the new, more serious, embargoed one.

But it isn't two bugs, it's an entire class of bugs. It's like a new field of bug: It isn't just that we can use TSX to infoleak address information and defeat randomization (the map), because there are techniques using double page-faulting and prefetching too that were demonstrated to potentially disclose address information. So it was already open season in the tall grass, the only question was how many ducks were in there.

It turns out, since this embargo is almost certainly about an arbitrary read, that the mother of all ducks was in there too (real-time, country-wide video satellite). Oh, and there's probably more than just one or there are multiple ways to catch it.

So we gots to drop the bomb on it. Only way to be sure.
Last edited by Glorious on Wed Jan 03, 2018 1:54 pm, edited 3 times in total.
 
just brew it!
Gold subscriber
Administrator
Posts: 51036
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 1:48 pm

chuckula wrote:
If Zen doesn't implement the same type of speculative instruction execution feature that caused the bug in Intel chips then something tells me Bulldozer/Piledriver parts are highly unlikely to share the same bug.

You're probably right, but Zen is enough of a departure from Bulldozer/Piledriver design that I don't think we can take it for granted.
Nostalgia isn't what it used to be.
 
Ryu Connor
Gold subscriber
Global Moderator
Posts: 4301
Joined: Thu Dec 27, 2001 7:00 pm
Location: Marietta, GA
Contact:

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 2:08 pm

For that matter it's sort of irrelevant if current AMD processors are immune to a particular side channel flaw. I feel this is part of what Glorious is trying to convey to fyo. We've been living for years with a growing category of hardware flaws that bypass KASLR. The KAISER paper already had three and it looks like a fourth is about to appear. Why assume it's going to stop there? Most likely there will be a fifth and so on. These problems have been Intel specific at this time, but just because someone hasn't found a way to do it on AMD processors today, doesn't mean they won't find one tomorrow. So it looks like the kernel developers have decided we're all going to get this pill whether their is a known AMD flaw or not.
All of my written content here on TR does not represent or reflect the views of my employer or any reasonable human being. All content and actions are my own.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1773
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Intel Processor bug incoming?

Wed Jan 03, 2018 2:11 pm

Ryu Connor wrote:
For that matter it's sort of irrelevant if current AMD processors are immune to a particular side channel flaw. I feel this is part of what Glorious is trying to convey to fyo. We've been living for years with a growing category of hardware flaws that bypass KASLR. The KAISER paper already had three and it looks like a fourth is about to appear. Why assume it's going to stop there? Most likely there will be a fifth and so on. These problems have been Intel specific at this time, but just because someone hasn't found a way to do it on AMD processors today, doesn't mean they won't find one tomorrow. So it looks like the kernel developers have decided we're all going to get this pill whether their is a known flaw or not.


The PTI work does fix this bug, but the PTI work was not done *exclusively* because of this bug. It goes beyond this particular bug to address more issues with security in different memory spaces that is particularly important in virtualization. As I said above, the long-term solutions will include new hardware to implement the page table isolation more efficiently than can be done in software.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 8

Who is online

Users browsing this forum: pirate_panda and 13 guests