Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

Page 62 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

LTC8K6

Lifer
Mar 10, 2004
28,520
1,575
126
I thought LTC8K6 was saying "you don't need to patch your home system", not "adding the patches won't affect performance", as the former interpretation makes a lot more sense to me.
AFAIK, you can't "not patch" your home system though.
 

LTC8K6

Lifer
Mar 10, 2004
28,520
1,575
126
So it seems that Intel cpus can't also protect read-only memory from speculative writes :

https://arstechnica.com/gadgets/201...es-speculative-execution-to-overflow-buffers/

This is really bad for server cpu - I still wonder how Intel can suffer so mildly from this kind of cpu misbehaviour.....

I think it must be that the predicted impacts have simply not been as bad as forecast, or the patches are working better than expected?

AMD is vulnerable to Spectre variants as well, so presumably this also affects AMD? It's apparently a V1 variant?
 

scannall

Golden Member
Jan 1, 2012
1,944
1,638
136
AMD is vulnerable to Spectre variants as well, so presumably this also affects AMD?
It's unclear. AMD is more resistant to Spectre 2, and immune to Meltdown for instance. It could be? Sure, but the article doesn't say one way or the other.
 

PingSpike

Lifer
Feb 25, 2004
21,729
559
126
AMD is vulnerable to Spectre variants as well, so presumably this also affects AMD? It's apparently a V1 variant?

Hard to say. You can parse this paragraph a few different ways. The description here makes it sound like meltdown only using writes but I feel like that can't be the whole story.

This speculative execution can even do other things that wouldn't be allowed: for example, Intel processors allow speculative writes to be made to read-only memory, giving even more power to an attacker. This has some similarity to the Meltdown attack; Intel and certain ARM processors (though not AMD chips) will allow user-mode programs to speculatively read kernel-mode memory because of the way the processors defer checking whether the access is permitted. It turns out that they also defer checking whether a write is permitted, too.
 

naukkis

Senior member
Jun 5, 2002
702
571
136
Since it's a V1 variant, odds are pretty good that AMD is vulnerable as well. The paper itself doesn't seem to indicate that AMD processors were tested.
/

This vulnerability needs that cpu doesn't respect memory privilege levels when running speculative code - this is Meltdown-type vulnerability.
 

LTC8K6

Lifer
Mar 10, 2004
28,520
1,575
126
So version 1.1 might work on AMD too, but V1.2 is for cpus that don't respect memory privileges - Intel and some ARM designs.
I think both are going to affect AMD. AMD is vulnerable to V1 and likely vulnerable to all variants of V1.

AMD has been sent the info, but I don't think they have responded yet. I'm sure they will, until then we can just wait.
Also realize that for most home users, these are all still basically a non-issue.

And:

To exploit, similarly to most previous Meltdown and Spectre bugs, both vulnerabilities require the presence of malicious code on a user's PC, code responsible for running the attack.
 

naukkis

Senior member
Jun 5, 2002
702
571
136
I think both are going to affect AMD. AMD is vulnerable to V1 and likely vulnerable to all variants of V1.

AMD has been sent the info, but I don't think they have responded yet. I'm sure they will, until then we can just wait.
Also realize that for most home users, these are all still basically a non-issue.

And:

This is documented on that whitepaper:

1.2 Spectre1.2: Read-only Protection Bypass Spectre3.0, aka Meltdown [39], relies on lazy enforcement of User/Supervisor protection flags for page-table entries (PTEs). The same mechanism can also be used to bypass the Read/Write PTE flags. We introduce Spectre1.2, a minor variant of Spectre-v1 which depends on lazy PTE enforcement, similar to Spectre-v3. In a Spectre1.2 attack, speculative stores are allowed to overwrite read-only data, code pointers, and code metadata, including vtables, GOT/IAT, and control-flow mitigation metadata. As a result, sandboxing that depends on hardware enforcement of read-only memory is rendered ineffective.



So this V1.2 affect only cpus which don't respect privilege levels when executing speculative code. This vulnerability won't effect much on desktop users - but for server side any hardware sandboxed runtime environment can't keep secrets - and fixes will be downgrade performance at best case - reduced security might still be inevitable.

But that likely not bring down Intel value and sales at all, yet better they probably will broken every sales records after they have fixed hardware to sell and will begin to recommend retiring Meltdown-affected cpu from security reasons......
 

LTC8K6

Lifer
Mar 10, 2004
28,520
1,575
126
This is documented on that whitepaper:

1.2 Spectre1.2: Read-only Protection Bypass Spectre3.0, aka Meltdown [39], relies on lazy enforcement of User/Supervisor protection flags for page-table entries (PTEs). The same mechanism can also be used to bypass the Read/Write PTE flags. We introduce Spectre1.2, a minor variant of Spectre-v1 which depends on lazy PTE enforcement, similar to Spectre-v3. In a Spectre1.2 attack, speculative stores are allowed to overwrite read-only data, code pointers, and code metadata, including vtables, GOT/IAT, and control-flow mitigation metadata. As a result, sandboxing that depends on hardware enforcement of read-only memory is rendered ineffective.



So this V1.2 affect only cpus which don't respect privilege levels when executing speculative code. This vulnerability won't effect much on desktop users - but for server side any hardware sandboxed runtime environment can't keep secrets - and fixes will be downgrade performance at best case - reduced security might still be inevitable.

But that likely not bring down Intel value and sales at all, yet better they probably will broken every sales records after they have fixed hardware to sell and will begin to recommend retiring Meltdown-affected cpu from security reasons......
They didn't do any AMD testing, and AMD is vulnerable to Spectre V3a.

Anyway, soon AMD will respond to the new threats and that will be that.
 

LTC8K6

Lifer
Mar 10, 2004
28,520
1,575
126
Don't forget all the lawsuits against AMD and Intel over these vulnerabilities. Those add pressure as well.
 

naukkis

Senior member
Jun 5, 2002
702
571
136
They didn't do any AMD testing, and AMD is vulnerable to Spectre V3a.

V3a is different, this vulnerabilities, Meltdown and Spectre V1.2 needs that CPU do late privilege checks. Meltdown did not affect AMD because AMD do privilege checks also for speculative loads, and if they do it also for stores they aren't effected with V1.2

V1.2 is different from other vulnerabilities as there's possibility to run attachers own code with host program privileges(or there is big possibility it's ring0 privileges) - it's a very powerful tool for hackers.
 
Last edited:
May 11, 2008
19,306
1,131
126
This article from Arstechnica explains the new issue perfectly.
The new spectre variant looks a bit like meltdown which AMD cpus are immune for, but not Intel cpus and some specifc ARM cpu versions.
But it also looks a bit like spectre does which AMD cpus are in some degree susceptible to.
I am very interested in how this is going to unravel.
https://arstechnica.com/gadgets/201...es-speculative-execution-to-overflow-buffers/

An excerpt:
This speculative execution can even do other things that wouldn't be allowed: for example, Intel processors allow speculative writes to be made to read-only memory, giving even more power to an attacker. This has some similarity to the Meltdown attack; Intel and certain ARM processors (though not AMD chips) will allow user-mode programs to speculatively read kernel-mode memory because of the way the processors defer checking whether the access is permitted. It turns out that they also defer checking whether a write is permitted, too.

Full story
When the Spectre and Meltdown attacks were disclosed earlier this year, the expectation was that these attacks would be the first of many, as researchers took a closer look at the way that the speculative execution in modern processors could be used to leak sensitive information and undermine the security of software running on those processors. In May, we saw the speculative store bypass, and today we have a new variant on this theme: speculative buffer overflows, discovered by Vladimir Kiriansky at MIT and independent researcher Carl Waldspurger.
All the attacks follow a common set of principles. Each processor has an architectural behavior (the documented behavior that describes how the instructions work and that programmers depend on to write their programs) and a microarchitectural behavior (the way an actual implementation of the architecture behaves). These can diverge in subtle ways. For example, architecturally, a program that loads a value from a particular address in memory will wait until the address is known before trying to perform the load. Microarchitecturally, however, the processor might try to speculatively guess at the address so that it can start loading the value from memory (which is slow) even before it's absolutely certain of which address it should use.
If the processor guesses wrong, it will ignore the guessed-at value and perform the load again, this time with the correct address. The architecturally defined behavior is thus preserved. But that faulty guess will disturb other parts of the processor—in particular the contents of the cache. These microarchitectural disturbances can be detected and measured, allowing a malicious program to make inferences about the values stored in memory.
The new attack is most similar to the array bounds check variant of Spectre. This attack takes advantage of a common coding pattern: before accessing the Nth element of an array, a program first checks that the array has an Nth element to access by comparing N to the size of the array. In most cases, that comparison succeeds, so the processor will speculatively assume that the comparison is OK and blindly try to access the Nth element.
In the Spectre attack, an attempt is made to read an element that doesn't exist. The speculative access will therefore try to read memory that isn't part of the array. This speculatively read data can then be used to disturb the processor's cache in a detectable way. When the processor notices that the element doesn't exist and that the read shouldn't be performed, it will cancel the speculative execution. But the cache remains disturbed. This disturbance means that an attacker can make inferences about the data that was speculatively read.

If reads work, then how about writes?
How security flaws work: The buffer overflow
The new attack is a natural counterpart to this original Spectre array bounds attack. The difference is that, instead of attempting to read an array element that doesn't exist, an attempt is made to write an array element that doesn't exist.
Writing beyond the extents of an array is a well-known attack method, known as a buffer overflow. It can be tremendously powerful, allowing an attacker to execute code of their choosing and completely compromise a buggy application. Buffer overflows gain their power because programs often store addresses of code adjacent to data in arrays, with the processor using these code addresses to determine which instructions to run each time a function call is completed. Overflowing the buffer allows this code address to be overwritten, which in turn means that the attacker can trick a program into running code of their choosing.
The main way of preventing buffer overflows is to check that each attempt to access an element of an array is an attempt to access an element that actually exists. But this is where Spectre comes into play. Even if the program is correctly written and checks that every array access is valid, the processor can speculatively attempt invalid accesses. These invalid accesses can do things such as (speculatively) write outside the bounds of an array. The speculative writes can do things such as overwrite code addresses in the same way that traditional buffer overflows work.
These speculative buffer overflows can therefore cause the processor to speculatively execute code of an attacker's choosing. The processor assumes that a write to a buffer is safe (even though it actually overflows the buffer), and it speculatively overwrites a code address. The code at that address is then speculatively executed, causing a measurable disturbance to the processor's cache. Eventually, the processor will notice that the array access was invalid, and all the speculative execution will be rolled back. The buffer isn't actually overflowed. But the disturbance to the processor's state, in particular to its cache, doesn't get undone.

This speculative execution can even do other things that wouldn't be allowed: for example, Intel processors allow speculative writes to be made to read-only memory, giving even more power to an attacker. This has some similarity to the Meltdown attack; Intel and certain ARM processors (though not AMD chips) will allow user-mode programs to speculatively read kernel-mode memory because of the way the processors defer checking whether the access is permitted. It turns out that they also defer checking whether a write is permitted, too.

Similar problems have similar fixes

A range of software fixes has been devised for the original Spectre array bounds attack. These fixes work in two main ways. The first is to insert a delay between testing if an array element actually exists in the array and then using that array element. x86 processors already have a suitable function, and ARM has added a new instruction for ARM chips to achieve the same. These instructions essentially act to block speculative execution such that the processor must know definitively whether the array element exists or not before proceeding. This addresses the original Spectre variant, and it's equally applicable to the new version.

The second approach is to constrain the array elements accessed so that, for example, any attempt to speculatively access an element that doesn't exist is always directed at the first element of the array. Again, this approach is equally applicable for speculative reads as it is for speculative writes.

Moreover, techniques used to protect against conventional buffer overflows can also be useful against speculative buffer overflows. For example, one approach is to combine any sensitive code addresses with a secret key. The code addresses have to be decoded before being used. This is useful because any attempt to overwrite one of these addresses will write a value that hasn't been combined with the secret key; decoding the address will produce some invalid value, preventing an attacker from controlling which code is speculatively executed.

The researchers also propose a family of hardware changes that should offer broader protection against this kind of attack. These protections may be possible to implement in a microcode update, offering a way to protect software running on existing processors. Broadly speaking, the changes would prevent the processor from using the speculatively written values in other contexts. For example, they would block a speculatively written code address from being used to control subsequent speculative execution. Such modifications may also prove useful in protecting against the speculative store bypass attack from May.

In response to the new findings, Intel has offered updated guidance to developers on how to avoid speculative execution-based attacks.
 
  • Like
Reactions: lightmanek

coercitiv

Diamond Member
Jan 24, 2014
6,151
11,686
136
Update from AMD:

Spectre Mitigation Update - 7/13/18
This week, a sub-variant of the original, Google Project (GPZ) variant 1 / Spectre security vulnerability was disclosed by MIT. Consistent with variant 1, we believe this threat can be mitigated through the operating system (OS). AMD is working with the software ecosystem to mitigate variant 1.1 through operating system updates where necessary. We have not identified any AMD x86 products susceptible to the Variant 1.2 vulnerability in our analysis to-date. Please check with your OS provider for the latest information.

AMD has also updated related portions of the Software Techniques for Managing Speculation on AMD Processors whitepaper.
 

LTC8K6

Lifer
Mar 10, 2004
28,520
1,575
126
That's what others speculated. AMD is vulnerable to the new 1.1, but probably not to the new 1.2, and they will rely on the OS maker to deal with it.

So really, nothing new to worry about for Intel or AMD home users.
 
May 11, 2008
19,306
1,131
126
That's what others speculated. AMD is vulnerable to the new 1.1, but probably not to the new 1.2, and they will rely on the OS maker to deal with it.

So really, nothing new to worry about for Intel or AMD home users.

It is indeed the case that the user must have some malware installed first that takes advanatge of these leaks.
But then i think about hacked commercial content providers that happened in the recent past and security leaks in browsers that allow a tainted simple image or tainted video content from a commercial content provider to execute code to install malware like trojans or viruses or worms. These are dangerous times.
Or java scripts...

https://en.wikipedia.org/wiki/Malware
 
  • Like
Reactions: DarthKyrie

coercitiv

Diamond Member
Jan 24, 2014
6,151
11,686
136
Hardware Unboxed - Intel's Spectre V4 Performance Explored, Speculative Store Bypass
TL;DR Windows users won't see any meaningful performance drop.

 

Gideon

Golden Member
Nov 27, 2007
1,608
3,573
136
https://grahamc.com/blog/an-epyc-nixos-build-farm

A very interesting blog-post about NixOS build ecosystem speed on two packet.net instances:

System Comparison:

m1.xlarge.x86 (Broadwell Xeon)
CPU: 24 Physical Cores @ 2.2 GHz (2 x Xeon® E5-2650 v4)
RAM: 256 GB of ECC RAM

c2.medium.x86 (EPYC)
CPU: 24 Physical Cores @ 2.2 GHz (1 x AMD EPYC™ 7401P)
RAM: 64 GB of ECC RAM

The interesting part?
EPYC instance is about 30-40% faster across the board. That is despite the Xeon server having the same number of cores (24), very similar IPC and clock speed (not to mention 4x the RAM).

I highly highly doubt that packet.net misconfigured their old Xeon instances in some way (considering the cost) ...

While it's anyone's guess, I can't seem to think of any other reason for this discrepancy than Meltdown and Spectre patches.