Intel impacted by SWAPGS vulnerability

All of these intrusions are variations of the oldest virus vectors - execution fishing (making bytes from a read file look like an executable), address execution (telling the processor to execute a command found at a certain location), and unrestricted execution (allowing a processor to execute a command, even if it's not part of the current task). I'll admit that those are simplistic descriptions for some complex ideas, but it's basically what a lot of these attacks boil down to. They've been around since the 80's. They don't seem the same, but honestly they all come back to a few concepts executed in new places (pipelines and predictors), with new tools and a greater understanding of core design and core-specific assembly language. Hackers are just getting more sophisticated at finding ways to perpetuate them.

Would a CPU manufacturer like Intel be dumb enough to allow address execution and unrestricted execution happen inside their hardware? Sure they would - would a company like Microsoft be dumb enough to create Internet Explorer 6?

Is AMD as vulnerable? Probably not, or the Intel supporters would have demonstrated it by now. It's not hard to force your hardware to keep track of the executables it loads, it's not hard to make it refuse to execute anything it finds in a data stream, and it's not hard to double check if an instruction was a logical result of a previous instruction. But those activities use processor cycles and they use more cache. AMD might have built a design where most of those things didn't happen.

Why hasn't Intel fixed all this in hardware? It might not be that simple. Some fixes could require a reworking of their schema, or even reworking the formulary of their asm.


P.S. Hot DAMN, I love it when I talk like a know-it-all! I'm rubbing the bottom side of my keyboard right now!
 
All of these intrusions are variations of the oldest virus vectors - execution fishing (making bytes from a read file look like an executable), address execution (telling the processor to execute a command found at a certain location), and unrestricted execution (allowing a processor to execute a command, even if it's not part of the current task). I'll admit that those are simplistic descriptions for some complex ideas, but it's basically what a lot of these attacks boil down to. They've been around since the 80's. They don't seem the same, but honestly they all come back to a few concepts executed in new places (pipelines and predictors), with new tools and a greater understanding of core design and core-specific assembly language. Hackers are just getting more sophisticated at finding ways to perpetuate them.
...

No. These attacks exploit side effects in the micro-architectural state ie. stuff like inter-instruction state bleed.
Prior to these disclosures, attacks were executed through completely different attack vectors by exploiting architectural vulnerabilities.

micro-arch -- what only the hardware *should* see or properties of the actual design; core internal dataflow, physical design (ie. exotic attacks exploiting stuff like measuring voltage patterns to deduce code behavior), logic design, etc.
architecture -- what the programmer/OS sees or how things are presented to the world; things like registers, MMU, etc.

You are correct that this requires relatively deep knowledge of CPU architecture, but stuff like "core-specific assembly language" *has* actually been around forever - it's generally called an ISA and every CPU arch has one.

I think many people don't really understand just how complex modern CPUs and CPU design actually is. By extension, the people discovering and proving attack vectors like this are incredibly intelligent and knowledgeable with a very deep understanding of CPU design. Brushing that aside with "They've been around since the 80's" is complete bullshit, sorry.
 
Prior to these disclosures, attacks were executed through completely different attack vectors by exploiting architectural vulnerabilities.

I believe I said that I was using simplistic descriptions. And at their root level, they are the same - they are going to place malicious code and trick the system into executing it. The idea that the attack has been hidden in the predictor of a core that is not being used, and that the attack is going to bullox a friendly process in a way that causes the process to borrow from the corrupted core, is all very impressive and all above what I used to do for a living. However, it's still the same concept - the Grandparent Scam is the same scam, no matter if its done with telegraph, mail, text or a cell phone.

And I was talking about assembly language because I attended a doctoral presentation on the branch prediction bugs last Christmas (I was visiting an friend who was on the committee, I understood about half of what was said, but I am well-trained at holding a Starbucks cup and looking professorial), and one of the key points the research covered were the changes in assembly language that allowed a multi-core system to borrow resources from other cores and load (or not load) a failed process into the resources of a different core.

So ... if we're talking about the same thing, I give you my blessings. If you're talking about something else, please link, I'll probably read it. Or if you can keep it concise enough, a series of links might make a good thread for this board.


P.S. I admit, my background is programming, not microarchitecture, but I'm not stupid. I try to keep up. In fact, my girlfriend says I'm cretinous, and she's not talking about my hair!
 
Last edited:
Please link technical articles! I love reading these things and loved your two posts. Thanks!
 
Never. Impossible to create a 100% secure anything.

Apple users felt for the longest time they where invulnerable, turns out it mostly just wasnt worth the effort for the hacker due to low population.

Once something crosses the "profitability" line, it gets hacked.
Maybe this is true, but AMD seems to be immune to a lot of these things...
 
Last edited:
security by obfuscation. Always focusing where the biggest blast radius can happen.
It's easy to say that, but AMD specifically states that they avoided the same shortcuts that Intel took due to security concerns.... so.. if they are to be believed (that's on you) they did this on purpose, rather than just got lucky. Seeing as they cross license almost the entire core (instructions, obviously some differences in implementation) very similar shortcuts would have been available to engineers from both companies. Of course one can argue they had no clue how to optimize their CPU and just got lucky they didn't screw it up, but without proof, hard to say, but I feel like these types of shortcuts were pretty obvious to an engineer in their position so consciously decided against it. Believe or don't believe, without proof you can't be certain either way.
 
That's why their IPC is so good for so long...
Yes, this is one of the reasons... the other is because... well, Bulldozer, haha. However, having to patch all these purpose built flaws that they finally got caught out on has allowed AMD to catch up very quickly with Ryzen.
 
Yes, this is one of the reasons... the other is because... well, Bulldozer, haha. However, having to patch all these purpose built flaws that they finally got caught out on has allowed AMD to catch up very quickly with Ryzen.

I'm still rocking Bulldozer and Piledriver in a couple machines. Years and years at 4.6-4.8 GHz @ 1.45v... dang things wont die. Meanwhile my old Q6600 wont overclock anymore and runs like a 486 with all the security patches.

Bulldozer was always going to be at an IPC disadvantage (8 small cores vs Intel's 4 big cores), but for similar or less cost than an i5 you got i7 level multi-threaded performance and perfectly good single-threaded performance for 1080p gaming. Now that we know Intel's IPC advantage was inflated it actually seems like a pretty good chip.
 
Please link technical articles! I love reading these things and loved your two posts. Thanks!

The Spectre/Meltdown whitepapers are actually pretty good and "readable" (by paper standards hah).
This article is a pretty good overview without getting lost in technical details:


If you need to brush up a bit on modern CPUs without watching lectures - this is quite excellent: http://www.lighterra.com/papers/modernmicroprocessors/

Edit: why the hell does the link to medium force-expand to a MEDIA block?
 
Seriously lets just say intel impacted by everything. Haha. Its becoming a joke at this point.
 
Seriously lets just say intel impacted by everything. Haha. Its becoming a joke at this point.
They really need to start implementing hardware-level fixes in their CPU architectures for future designs.
The performance impacts are ridiculous at this point, and have basically killed off all CPU architectures pre-Sandy Bridge (assuming the OEMs are patching back this far - many are not) for anything outside of stand-alone builds.
 
Back then they should have touted it:' Intel UN- secured processing' delivering industry leading 10% uplift in IPC.
 
I'm still rocking Bulldozer and Piledriver in a couple machines. Years and years at 4.6-4.8 GHz @ 1.45v... dang things wont die. Meanwhile my old Q6600 wont overclock anymore and runs like a 486 with all the security patches.

Bulldozer was always going to be at an IPC disadvantage (8 small cores vs Intel's 4 big cores), but for similar or less cost than an i5 you got i7 level multi-threaded performance and perfectly good single-threaded performance for 1080p gaming. Now that we know Intel's IPC advantage was inflated it actually seems like a pretty good chip.
Like you said, it was always going to be at an IPC disadvantages that was my only point. I ran AMD pretty much soley until then (I think it still have my phenom ii x3 720 BE that I was able to overclock and unlock the 4th core). They were ok processors but mutlithreading wasn't really well supported and AMD didn't have the resources to spend with developers making it work. If they did, their core advantage would have helped them more. That is changed now and AMD has increased IPC to catch up.
 
The Spectre/Meltdown whitepapers are actually pretty good and "readable" (by paper standards hah).

That was good - much better than the presentation I attended. Actually, that's not fair - I'm sure the presentation was good, it was just way outside my specialty. I was there to fill a seat because the university is a ghost town during Christmas break, but they still like to have a full room when someone presents their thesis.

These things always seem obvious in hindsight.

Sun: "JAVA is a universal platform for everyone, so we're going to let the people of the world write tools, extensions, libraries and snippets that we will make available to all, and we'll even allow for push updates! What could go wrong?"
Microsoft: "We're going to make IE6 so that the internet can interact with your computer! What could go wrong?"
Adobe: "We're going to make Flash so that the internet can interact with your computer! What could go wrong? Shut up, Microsoft..."
Intel: "We're going to dance naked in the forests of Yosemite while smeared in fish guts. WHAT COULD GO WRONG? Oh, and we're going to make all memory, cache's and pipelines addressable and accessible, 'cause SPEEEED."


P.S. Of course, I'm a hypocrite, because when Microsoft released Internet Explorer 6 and the associated Visual Studio with VB Script, I was seriously in love with it. At the time we were using Pro*C/C++ and PL/SQL (from Oracle) to generate web reports and forms, and I didn't like it. I told everyone in my department that this Microsoft stuff was the hot iguana, it was going to be famous, it would blow the internet wide open, and I was right.

That was almost 20 years ago, and my old office mate, Jeff, still shoves that up my ass from time to time.
 
Last edited:
Back
Top