add arrow-down arrow-left arrow-right arrow-up authorcheckmark clipboard combo comment delete discord dots drag-handle dropdown-arrow errorfacebook history inbox instagram issuelink lock markup-bbcode markup-html markup-pcpp markup-cyclingbuilder markup-plain-text markup-reddit menu pin radio-button save search settings share star-empty star-full star-half switch successtag twitch twitter user warningwattage weight youtube

Get Ready to Buy Your Intel CPU Again

ewhac

25 months ago

If you own a system with an Intel CPU manufactured some time in the last ten years, a design flaw has been discovered that has OS vendors scrambling to put a patch in place:

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

The precise nature of the bug is under wraps until the software workarounds are in place and have been deployed. The issue appears to be that user-level software (such as JavaScript running in Web browsers) can, through a series of subtle timing attacks, discern the contents of memory pages it normally would not have the privileges to access. The implications are that a malicious Web page can poke around and try to recover sensitive information stored in memory, such as passwords and private encryption keys. (Even successfully grabbing just a handful of bits of an encryption key can hugely shorten the time required to perform a brute-force attack.)

For a desktop machine, the issue can maybe be ignored, provided you keep your Web browser up to date and properly configured to not execute arbitrary JavaScript. The greatest impact is on shared hosting platforms/providers, such as Amazon Web Services -- a malicious process in one virtual machine can try and suss out sensitive data running in other virtual machines.

Both Microsoft and the Linux kernel developers are working on updates, with FreeBSD believed to follow shortly. Mac OS X will also need an update. The OS workarounds being put together will reduce the performance of your Intel PC from 3-30% -- possibly more -- depending on the nature of the workload. Further, the flaw is such that a fix in CPU microcode is not possible. So to be rid of the issue and get your performance back, you'll have to buy your Intel CPU again once they've fixed the HW.

This is probably Intel's biggest CPU design blunder since the Pentium floating point bug and the F00F bug.

AMD CPUs are apparently not affected by the issue. So all you Ryzen-heimers can enjoy an extra helping of smug :-).

Update

The details of the exploit have been released: https://meltdownattack.com/

Comments

  • 25 months ago
  • 4 points

This has already been gone over in other threads. As far as we know, the performance hits impact server workloads much more than gaming. The actual impact for most tasks has been tested to be less than 10% (usually less than 5% too), and performance difference in games has been marginal.

TL;DR the media is blowing this out of proportion to get clicks/views.

  • 25 months ago
  • 2 points

10% or even 5% less performance than what I payed for is a big deal!

  • 25 months ago
  • 2 points

10% or even 5% in specific workloads, most of which don't affect consumers. There have been quite a few benchmarks out showing game performance drops to be less than 1%.

  • 25 months ago
  • 2 points

And, from what I have seen, only when the CPU is the largest bottleneck (1080p @ lowest settings). So, in situations where this isn't the case, the effects will be even less substantial.

  • 25 months ago
  • 4 points

There is an embargo on this. And won't be lifted until the 10th. So anything meaningful won't be released until then. Most of the IT staff at my company (those that are willing to talk about it to a point) are saying its a wait and see game. But non of them are all that worried about it.

They do get a kick out of all the over reactions going on.

I doubt its going to be as serious as the net's making it out to be. It's a serious situation, but any chance to jump on the OH SNAP INTEL F'ED UP bandwagon people will take it.

  • 25 months ago
  • 1 point

Might want to give this a read.

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.computerbase.de%2F2018-01%2Fintel-cpu-pti-sicherheitsluecke%2F%23update2&edit-text=&act=url

Or not in english: https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

AMD CPUs are apparently not affected by the issue. So all you Ryzen-heimers can enjoy an extra helping of smug :-).

The changes can have a massive impact on AMD as well EPYC took up to a 49% hit.

Although as the benchmarks show above the normal uses impact is effectivly minimal even on Intel based systems.

  • 25 months ago
  • 2 points

Same comment on your link says this however:

The fact that this benchmark was implemented on an AMD system, even though AMD CPUs are not affected by the vulnerability and that PTI is superfluous there as it stands, is not without its irony. Reason to assume that the performance losses on Intel CPUs would be significantly different, but there is not. Nevertheless, this benchmark is probably the absolute worst case and in less specific benchmarks, the performance losses are likely to be significantly lower or barely measurable.

AMD further also put out a statement:

Chipmaker Advanced Micro Devices on Wednesday pushed back on a statement from Intel about a recently documented security flaw, saying its chips are mainly not affected.

AMD expects to publish security research on the flaw later on Wednesday but did provide an initial statement of its own:

To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time.

https://www.cnbc.com/2018/01/03/amd-rebukes-intel-says-flaw-poses-near-zero-risk-to-its-chips.html

Personally I would venture when the fix does come out for Windows the impact will not be as significant as we think for both parties. In the event AMD is affected, I can imagine a subsequent patch removing AMD being forced to use for them a superfluous patch which only negatively impacts performance if as AMD indicate there architecture means the fix is not needed for there CPU's. I would imagine however at this point, to get the fix out as quickly as possible, just getting it out for CPU's affected / not affected is not a priority. Just my two cents.

  • 25 months ago
  • 1 point

Edited the above to clarify a better responce thanks meds are getting to me.

I can imagine a subsequent patch removing AMD being forced to use for them a superfluous patch which only negatively impacts performance if as AMD indicate there architecture means the fix is not needed for there CPU's.

Depends mostly because of.

To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants.

So they do have a weakness in the design, and can be exploited.

But I agree case like this its best to fix the issue first and find performance fixes later.

  • 25 months ago
  • 1 point

The changes can have a massive impact on AMD as well EPYC took up to a 49% hit.

Yes, if you enable the workarounds. But AMD claims that the underlying flaw is not present in their architecture, so the kernel workarounds are unnecessary, and can be safely disabled on AMD-based systems. (That's what AMD is claiming, anyway.)

  • 25 months ago
  • 1 point

As Radox-O pointed out AMD themselves admit to having a problem although they don't feel it is an issue at this time.

To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time.

Which means they will have little choice but to enact the fixes now or in the future.

  • 25 months ago
  • 1 point

Hopefully the AMD aspect will be a non-issue very soon. Apparently a patch is being pushed through for LINUX according to tweets on Ryan Shrout's twitter: https://twitter.com/ryanshrout?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor

and also here: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI in that the AMD patch will be honored and is currently sitting on a Known tree and will flow into either 4.15 (few weeks away) or 4.16. to reverse the affect of hammering every CPU needlessly with the fix.

Hopefully windows patch will follow soon for AMD if they rollout with the fix enabled for every CPU by default.

  • 25 months ago
  • 1 point

Maybe I am wondering now what was able to be exploited on AMD CPU if it isn't the same.

Intel is known now with leaving 2 of 3 exploitables up in the air.

To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time.

One of the others must be what they are referring to with " and AMD is not susceptible to all three variants." If it was none they would have stated that.

  • 25 months ago
  • 1 point

If it was none they would have stated that.

Exactly how I took that statement.

  • 25 months ago
  • 1 point

AMD is going with OS and Software patches to fix the issues.

https://www.amd.com/en/corporate/speculative-execution

Looks like varient 2 is "Meltdown".

  • 25 months ago
  • 1 point

Unless I am mistaken, at this point in time however the Varient affecting AMD has been limited at this point to older platform's, namely an FX CPU from google's project zero team: https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Of course by the same token they only tested older Intel CPU's but if the logic there has remained the same on Intel's side, could very well be why it still affects newer CPU's.

Now remains to be seen what the impact is to Ryzen / TR and I could very well imagine until the embargo lifts it will all be clouded either way, but given AMD seem confident enough to be able to get a patch out which removes the need for the fix which impacts performance, seems a non-issue for them. But gut feeling says AMD in wording only care about Zen and saying its all fine (referring mostly to zen) while everyone else care's about the whole product stack.

  • 25 months ago
  • 1 point

The details of the exploit have been released: https://meltdownattack.com/

The primary attack is reading data from memory to which you normally would not have access. The data is obtained via a cache timing side-channel. All physical memory is vulnerable.

Nearly all modern CPUs feature speculative execution -- the process of pre-fetching instructions from memory and doing some of the preliminary work (fetching values from memory, determining whether branches will/won't be taken, etc.) so that when the time comes to do the actual operation, most/all of the pieces are already in place, and the instruction retires quickly.

Question: What happens to all that prefetched work if an earlier instruction triggers a fault (reads unmapped memory, divides by zero, etc.)? The CPU starts fetching new instructions from the exception handler, and all that previous work is thrown away.

...Or is it?

The exploit works like this:

  • Allocate a large amount of memory. None of this memory has been touched by the CPU yet, so none of its values are in L1 cache.
  • Write code containing an operation that deliberately triggers an exception.
  • Immediately after that, place code that does an indexed read out of your allocated buffer, and whose index is taken from a kernel memory address. This code will be speculatively fetched and pre-processed, but will be abandoned because of the previous exception.
  • After returning from the exception handler, scan your large memory buffer, carefully timing how long it takes to read values out of it. One value at a particular offset will read much quicker than the others, because it was speculatively fetched into the L1 cache, based on the value in kernel memory. The offset where that happens is the same as the value in kernel memory. (In other words, if membuf[x] reads faster than any other offset in membuf, then the value in kernel memory was x.)

Yes, this is subtle voodoo. And yes, it breaks system security assumptions fairly badly, allowing you to read memory from the kernel or other processes that you're not supposed to be able to see. And yes, it's exploitable from JavaScript.

  • 25 months ago
  • 1 point

Two of the Three exploits.

And.

Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

Guess Intel wasn't wrong in that they are not alone in this.

Meltdown only seems to work on them but Spectre doesn't care what brand or platform.

  • 25 months ago
  • 1 point

Why will the performance decrease with the patch? When will the patch be released, and how would buying a new CPU fix the problem?

Anyways, I usually only do gaming, and looked online, and it seems I will be slightly affected in performance.

  • 25 months ago
  • 1 point

The workaround, as I understand it, is to forcibly evict kernel page map entries from the MMU -- or, as the Linux kernel developers phrased it: "Forcefully Unmap Complete Kernel With Interrupt Trampolines (*******)." That is to say, (nearly) all records of where the kernel's memory pages are located are erased from the MMU on return from system calls and exceptions. By doing so, speculatively-executed code hoping to pre-fetch some kernel memory into the L1 cache will instead encounter an unmapped page and not fetch anything, thereby not populating the L1 cache, and thereby preventing the Meltdown exploit from working (Spectre would still be an issue).

The slow-down happens when you make a system call into the kernel -- the MMU has to be re-populated with the kernel's page table. Loading that data into the MMU takes non-trivial time, and it has to be reloaded for every system call. The more system calls you make, the greater the performance impact.

Now that the CPU vendors are wise to this, presumably they will be revising the designs of their upcoming products to address/fix this kind of information leak, and next-generation parts won't need the software workaround, recovering the lost performance. But no one's announced anything yet.

  • 25 months ago
  • 1 point

So basically the L1 cache is going to act as if it does not exist?

  • 25 months ago
  • 1 point

Code running entirely on the kernel side or user side will still be able to make full use of the caches. It's just that, once you cross the boundary from user to kernel space and back, a whole bunch of extra work needs to be done, mostly involving the MMU. It's unclear whether they're flushing cache lines as well.

  • 25 months ago
  • 1 point

I’ll admit, I’ve never heard of kernel stuff. Can you explain it to me without it being super complicated? I don’t know why I’m asking now.

  • 25 months ago
  • 1 point

There's no TL;DR version of this, so get comfortable :-) ...

Let's say you have a program that wants to draw a green rectangle on the screen. Back in the days of, say, the Apple ][ computer, you'd crack open the programmer's reference manual, look up the memory address of where the screen pixels are stored, then write a program that wrote numbers to those memory addresses that displayed as green. And this worked perfectly well.

Question: What happens if Apple decides to change where the screen address is, or what number means "green"? Then your old program wouldn't work. You could write a second program, tuned to the new hardware specs... Or, you could call a set of abstract functions that did the job for you. To illustrate using a very bad example:

addr = GetScreenAddress();
val = GetPixelValue ("green");
*addr = val;

The functions GetScreenAddress() and GetPixelValue() would be provided by the computer's Operating System (OS). The OS "knows" all the fiddly little hardware details about your machine, so it will always hand you the correct values for your machine. All you need to remember are the function calls and what they do. So when Apple releases a new machine, a new OS will be included, and your programs will work without needing to be rewritten or even recompiled.

Now, suppose you have some smug, self-important, self-proclaimed programming god who snorts, "Bah! The OS is inefficient and slow! My code is blazingly fast! I will ignore the OS and write to the hardware directly!" (BTW, I used to be this guy.) Well, that's fine -- sorta -- if only one single program is ever running on the machine at any given time, and you don't mind re-writing the program for every single trivial hardware variant out there. And in the bad old days of CP/M and MS-DOS, that used to be the case. But then came along this thing called a multi-tasking OS.

Multi-tasking OSs provide the illusion that more than one program is running at the same time. How this is actually accomplished is the subject of several semesters of a computer science curriculum. The point is that, suddenly, the hardware resources in your computer become shared among multiple programs. And the program written by That Guy who bypassed the OS and stomped on the HW directly is going to have a fight with and/or break every other program running in the system, possibly even the OS itself. (This in fact happened a lot, either deliberately or accidentally, on the Amiga computer and, much later, on Windows 3.1/95/98.) And thus was born the notion of privilege levels.

"Privileged" programs can read and write anywhere in memory, talk to any device, open any network connection, even spray raw unformatted bits down the network link. "Unprivileged" programs have much more stringent limits -- they can only access a limited amount of memory, and they can't talk to any hardware device directly. The OS also sets up a "wall" around the program such that, if it makes an attempt to access anything outside the barrier, it will either receive an error, or the OS will kill it outright. Thus, the program written by That Guy would just die. The rest of the system would continue on its merry way, protected from its fiddling.

But unprivileged programs can make function calls into the OS to request resources and services, perform operations and, yes, draw green rectangles on the screen.

The core of the operating system is colloquially known as the "kernel", and it executes in a privileged context. It can do and touch any damned thing it wants. Moreover, it arbitrates access to all of the hardware's resources among all the running programs. It keeps track of who has what memory, manages the filesystem on the HDD/SSD, runs the networking protocols, and tons of other things. As you might imagine, this requires a lot of bookkeeping; all such information is contained in memory which only the kernel has access to (unprivileged programs trying to read it hit a wall and either get nothing or get killed). After all, you don't want just anyone snooping through the kernel's lists trying to figure out what the program next door is doing/who it's talking to/what files it's writing/etc.

The Meltdown bug cracks this barrier between the privileged kernel space and unprivileged user space, thereby allowing unprivileged code to snoop on private kernel data -- or, indeed, any data anywhere else in the system, including other programs.

(Was that any help at all?)

Sort

add arrow-down arrow-left arrow-right arrow-up authorcheckmark clipboard combo comment delete discord dots drag-handle dropdown-arrow errorfacebook history inbox instagram issuelink lock markup-bbcode markup-html markup-pcpp markup-cyclingbuilder markup-plain-text markup-reddit menu pin radio-button save search settings share star-empty star-full star-half switch successtag twitch twitter user warningwattage weight youtube