Intel CPUs exploit

[Blokk]

Have you guys seen this recently?

https://gizmodo.com/report-all-intel-processors-made-in-the-last-decade-mi-1821728240

And Intel side: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr

https://downloadcenter.intel.com/download/27150?v=t

I am not really expert in computer security, is this really bad? Besides, they say the patch (if your mobo manufacturer makes any) might cause a 30% performance hit on your system...

[Blokk]

Right now they talk about this on BBC World News, mentioning the Intel stock prices went down too...

[Ben]

I had caught the headline but not the details until reading your linked pages.

While I can not speak to the details of the specifics related to the Intel chips, I can speak to what part of the architecture is affected and what it sound like they will have to do to fix it. I will try to summarize.

Early computers where just as most of the public is taught where there is a CPU accessing physical memory and I/O device to accomplish the programs they run. But those computers where the one that had to be boot-strapped to load the one and only program they executed and access to all of the hardware had to be explicitly implemented in the program themselves. There was no "Operating System".

Operating systems abstracted away the hardware details (you memory stick and hard-drive have file systems that look the same reagardless which you are using). When you "run" a program using a OS the OS is loading the program from disk into physical memory and the CPU is set to execute the first instruction in the program. So the access to the hardware is done by invoking calls to the OS that does the requested work and returns the results to the program that invoked the access to the I/O.

The other major functionality of the OS is to provide a "address space" for the program. This is done by using address translation hardware that will translate a "virtual address" to a physical address. This required the OS to set up the translation tables when a program was started and or when memory was allocated. The virtual memory allows multiple programs to run a what seems to be a machine of their own and they can all start at Program counter = 100 if they desire. The translation logic converts the address to a physical address in hardware.

I will skip over the details of memory cache and buss speeds for now.

The virtual address translation appears to be at the heart of this issue. It has been years since I have seen a blue-screen of death but those often came with the message "access violation". That access violation was trying to address a memory location that was not properly mapped in the translation hardware.

Given access to memory that is not part of your address space will let you look at physical memory that is not part of your program.

That is all I can say for now.

Thanks for the link and the head-up.

Ben

[Ben]

Another thought based on this issue ....

Spoiler

that I will write about now because chance to talk about this stuff does not come every day...

When memory final got cheap enough for us to by four or more Gig of memory where were faced with a limit of only being able to access 2-Gig of the four. A work-around was available that was called "3-Gig aware". That option let us use an additional gig of memory. I looked at that with a jaundice eye because of what had to be done to get at that extra memory.

Access to that extra Gig of memory required being able to set the most significant bit of the address to go above 2-Gig. When virtual memory schemes were first implemented it was not even imaginable that a program would use more than 2-Gig so the physical memory space was broken in half based on the most sig-bit. If it was set, it was OS, if it was clear it was a user program.

So something was done to allow access to the high addresses that did not result in an access violation.

Done with the trivia (for now).

Ben

[Hooovahh]

Oh and Intel is saying that the CEO selling off all of his stock (other than the minimum required to keep his job) has nothing to do with the fact that this vulnerability was reported by Google back in June.

On the technical side it sounds like there are two major bugs found.  One that only effect Intel, and one that seemly has a larger scope effecting AMD and ARM chips of some kind.  I'm going to quote reddit since someone there put it into words quite well.

Two major flaws in modern CPU architectures and our digital security.

The unfixable flaw affecting all CPU manufacturers is named Spectre. It'll be with us for years to come. I strongly suspect that it'll be a nightmare to live with, even if exploitation is more difficult than with the other one. Just about everybody is affected. Intel, AMD, ARM, Qualcomm... Exploitation isn't trivial, but not impossible either. Expect no fix until major CPU redesigns are done; potentially with performance impacts on future CPU generations, as designers have to be more careful with their current toolset (and these tools are a major part of what has sped up single thread performance since clock speeds stalled). This one primarily allows reading of information you should not have (memory) access to.

The other flaw is called Meltdown (this is the Intel bug that is currently being urgently patched for all major operating systems, which will cause performance issues in some workloads, and very little in others). Patching seems like a necessity as exploitation seems to be fairly reliably attained (already by third party researchers with incomplete pre embargo information), even if your Intel CPU gets slowed in the process. This will probably be targeted first, as it easily allows you to do essentially anything you want on the target system, so do patch your systems if running on Intel. 

---

[Ben]

There is something about the issues mentioned here that is nagging at me like there is an answer waiting to be questioned.

The performance/security issues seems to present a bit of a dilemma. Go with the patch and lose performance or risk the security to keep the performance up.

Just trying to be prepared!

Spoiler

Ben

[LV_Pro]

I can hear the screams of the gamers! Not to mention any high speed device, like smart TV's, etc, that "might" have the offending cpus, like all of them. Not a violent person, but really getting tired of those who are now called "hackers" (as opposed to a few decades ago, when it wasn't a pejorative).

The problem is that the "evolution" of personal computers and all of their relatives, was evolutionary, but started out relatively simply (I worked with 8008's at the beginning), with the OS's and hardware initially designed in an environment pretty devoid of the dangers seen today. As they "evolved" they have tended to be, at least for a while, as stuff duct taped onto preexisting stuff, to allow continuity of function. DOS was a copy of CPM/86, Windows was initially just a GUI on top of DOS, and etc. Even when new designs are created, who is possibly in the design/eval team that can see all the possible risks of "hacking"? Most hardware/software is so complex as to preclude any reasonable possibility of testing even a major subset of their functionality. It is one of the things that concerns me about "fly by wire" and "self driving (flying, etc.)", that there is no way, with the mammoth complexity, to test every case in a realistic (like years) time span. 

[crossrulz]

NI's first official reply: Processor Speculative Execution Vulnerabilities – Meltdown and Spectre

[Hooovahh]

Hack-a-day has had many posts on this topic over the last few days.  The last one I found interesting was some example code on how this exploit can actually be used which also highlights the fragility of the exploit but still.

https://hackaday.com/2018/01/11/meltdown-code-proves-concept/

And while we're at it here are some of the other posts that are an interesting read.

https://hackaday.com/2018/01/05/lets-talk-intel-meltdown-and-spectre/

https://hackaday.com/2018/01/06/lowering-javascript-timer-resolution-thwarts-meltdown-and-spectre/

https://hackaday.com/2018/01/07/go-retro-to-build-a-spectre-and-meltdown-proof-x86-desktop/

https://hackaday.com/2018/01/08/speculative-execution-was-a-troublemaker-for-xbox-360/

https://hackaday.com/2018/01/09/raspberry-pi-aint-afraid-of-no-spectre-and-will-not-meltdown/

https://hackaday.com/2018/01/09/getting-a-handle-on-meltdown-update-impact-stay-tuned-for-spectre/