By Next Week, Intel Expects To Issue Updates To More Than 90% of Processor Products Introduced Within Past Five Years (intel.com)

Intel said on Thursday that by next week it expects to have patched 90 percent of its processors that it released within the last five years, making PCs and servers "immune" from both the Spectre and Meltdown exploits. The company adds: Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years. In addition, many operating system vendors, public cloud service providers, device manufacturers and others have indicated that they have already updated their products and services.

Intel continues to believe that the performance impact of these updates is highly workload-dependent and, for the average computer user, should not be significant and will be mitigated over time. While on some discrete workloads the performance impact from the software updates may initially be higher, additional post-deployment identification, testing and improvement of the software updates should mitigate that impact. System updates are made available by system manufacturers, operating system providers and others.

Comments

Marketing

[Anonymous Coward]

Intel hasn't patched anything. Operating systems are trying to work around these bugs, but for some of the bugs, that's essentially impossible, and the only solution is to not run software that exploits these bugs.

Re:Intels updates also slow down AMD chips that do

[Anonymous Coward]

Bear in mind that there are two vulnerabilities, Meltdown and Spectre. Meltdown is currently Intel-only, but Spectre is Intel, ARM and AMD. Both use similar techniques to access kernel memory (Meltdown) and local process memory (Spectre).

Ref: https://isc.sans.edu/forums/diary/Spectre+and+Meltdown+What+You+Need+to+Know+Right+Now/23193/

Note that this info came from the above link, and the SANS discussion I attended over lunch today: There's a lot of changes happening with this right now.

Concise Summary Of The Flaw

[Anonymous Coward]

The flaw is concisely explained in this article.

https://spectreattack.com/spectre.pdf

In particular, it says the following.

Here is an example of exploitable code:

            if (x < array1_size)

                      y = array2[array1[x] * 256];

In this example, the variable x contains attacker-
controlled data. The if statement compiles to a branch
instruction, whose purpose is to verify that the value
of x is within a legal range, ensuring that the access to
array1 is valid.

For the exploit, the attacker first invokes the relevant
code with valid inputs, training the branch predictor to
expect that the if will be true. The attacker then invokes
the code with a value of x outside the bounds of array1
and with array1_size uncached. The CPU guesses
that the bounds check will be true, [then] speculatively exe-
cutes the read from array2[array1[x] * 256] using
the malicious x. The read from array2 loads data into
the cache at an address that is dependent on array1[x]
using the malicious x. The change in the cache state is
not reverted when the processor realizes that the specu-
lative execution was erroneous, and can be detected by
the adversary to find a byte of the victim's memory. By
repeating with different values of x, this construct can be
exploited to read the victim's memory.

Re:I'm confused by this.

[Kohath]

They’re changing the microcode to provide a mechanism for the OS kernel to implement the fix. They work together.

Re:True Scope Of Problem

[110010001000]

He is wrong. There are already PoC available that demonstrate "breaking out of a web browser". There is nothing magical about a web browser. It is just a program like any other.

Re:Intels updates also slow down AMD chips that do

[Anonymous Coward]

Intels updates also slow down AMD chips that don't have the bug as well. And AMD had to come out with there own update to back off the big slow down fix that Intel patch

This is both somewhat true and highly misleading. The team that releases the Linux kernel, headed by Linus, created a patch to address the issue. Programmers paid by Intel may or may not have contributed code to the patch, but regardless, accepting or rejecting their contribution was up to Linux and the normal kernel team. The original patch did not distinguish between AMD and Intel chips, but it was not in any sense an "Intel update." It was just a change to the way the kernel operates which mitigated the bug but also introduced some performance penalties. AMD programmers then provided another patch that bypassed the mitigation patch on AMD processors to avoid the performance penalties. This is standard procedure for not only the Linux kernel but most large software projects. Fix the vulnerability for everyone, then look at whitelisting situations which do not require the fix.

Re:Intels updates also slow down AMD chips that do

[Anonymous Coward]

None of this is right unless you're being sarcastic.

The fix that (at first) slows down AMD chips is a Linux kernel patch. It didn't come from Intel, at least not directly, and it only matters to Linux. It's likely that that version of the fix won't even get used on most systems because there are already better versions.

This whole article is talking about a microcode update, which is mini-firmware for the CPU. OS vendors need to deploy the update (you have to get microcode updates through the OS, though only CPU vendors can make them), but each CPU maker can only update their own CPUs. AMD is, naturally, not issuing any update here.

Re: Intels updates also slow down AMD chips that d

[buchanmilne]

Bear in mind that there are two vulnerabilities, Meltdown and Spectre. "Meltdown is currently Intel-only, but Spectre is Intel, ARM and AMD. Both use similar techniques to access kernel memory (Meltdown) and local process memory (Spectre)."

But the patches rolling out now are only for Meltdown, fixes for Spectre are still not merged and are being actively worked on (and require compiler changes, and patched kernels compiled with a suitably-patched compiler).

Re:Intels updates also slow down AMD chips that do

[Hal_Porter]

The AMD scheme does AES-128 on the fly when reading anything from DRAM (!)

https://lwn.net/Articles/69982...

There are two separate features-Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)-that both use the same hardware support that will be provided in upcoming processors. That support includes an AES-128 hardware engine inline with the RAM and memory controller so that memory can be encrypted and decrypted on the way in and out of the processor with "minimal performance impact". The data inside the processor (e.g. registers, caches) will be in the clear; there will just be a "little extra latency" when RAM is involved.

It seems like the ASIC (the AMD equivalent of Intel PCIDs which actually predates PCIDs) - is part of the AES key.

The hypervisor then allocates an "address space identifier" (ASID), which is what identifies the guest (and the key for that guest's memory). That ASID is provided to the secure processor with a request to generate or load a key into the AES engine and to encrypt the BIOS/OS image using that key. The hypervisor then sets up and runs the guest using the ASID assigned; the memory controller, AES engine, and secure processor will work together to ensure that the memory is encrypted and decrypted appropriately.

On the other hand it's aimed at hiding hypervisor data from guest OSs and vice versa. It's not designed to hide process or kernel data from other processes on the same OS. Then again AMD isn't vulnerable to the KPTI hole as far as I can tell - that's to do with Intel's implementation of speculative execution.

Of course AMD might be vulnerable to other bugs like this. Like you say, Spectre seems to affect "Intel, AMD and ARM".

https://www.exploit-db.com/doc...

Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim's process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices

If AMD are confident enough in their AES engine to put in in inline with the RAM and memory controller, they could probably work out how to make it do process isolation by encryption. E.g. if you could set it up so kernel memory was AES 128 encrypted with a random key then it would matter less if a user process was able to read it.

But what happens when you have virtualization? AMD's scheme protects guests from hosts. I'm not sure how you could additionally protect kernels in a guest OS from processes in that same guest OS.

Paid Intel shills will mention 'spectre'...

[Anonymous Coward]

There are PAID intel shills in this forum and on every other one across the net. Intel payolla outlets Anandtech, Tom's Hardware and Arstechnica have all consulted their Intel contacts and VERY late published FAKE NEWS articles letting Intel off the hook. But not every tech site takes large cheques from Intel...

If anyone here mentions 'SPECTRE', they are an Intel shill. Spectre is an 'exploit' that has no proven attack vector on AMD Ryzen parts, and the THEORETICAL vectors are simply patched on AMD with no performance hit. On Intel, Spectre CANNOT be patched, however. Either way, spectre is another TRIVIAL and insignificant bug- of which many thousands have already been dealt with on both AMD and Intel.

It is MELTDOWN that is the only issue that matters. Meltdown describes the NSA backdoor built into every Intel CPU designed to allow user code ring-0 access. This is an ARCHITECTURAL design of intel's CPU's, and cannot be fixed except by flushing and state resetting before EVERY virtual memory/IO operation- a massive slowdown of key functionality.

AMD's memory architecture is completely different, and does NOT allow this NSA requested attcak vector- not now, not ever.

Linux has gone crazy cos the exploit is a clear NSA backdoor, which Linux types will not accept. Microsoft, as an OS, is riddled with NSA exploits by Microsoft, so doesn't need a CPU hardware vector. Thus MS can happily patch the hole (on Intel only) at the cost of significant performance degradation on all mutli-core mulit-app use cases (which excludes most current games).

Intel cannot have a 'fixed' CPU til the end of 2019 at the earliest. Roadmapped Intel parts (like icelake) all have this NSA backdoor.

There is ZERO AMD issue- indeed AMD Ryzen is the future, just as the original AMD64 was the future when intel paid sites like this one to shill for the broken hopeless netburst design.

Re:Paid Intel shills will mention 'spectre'...

[110010001000]

Exactly. What is interesting is that Intel apparently got to CERT and made them change their solution from "replace the hardware" to "apply updates". Look at the difference between the two notifications:

Original CERT notification:
https://webcache.googleusercon...

Replaced CERT notification:
https://www.kb.cert.org/vuls/i...

Re:Intels updates also slow down AMD chips that do

[110010001000]

Exactly. As CERT originally said, the only solution is to replace your Intel processor:

Solution

Replace CPU hardware

The underlying vulnerability is primarily caused by CPU architecture design choices. Fully removing the vulnerability requires replacing vulnerable CPU hardware.

Re:Intels updates also slow down AMD chips that do

[complete loony]

Simple Meltdown attacks run within your own attacking process, bypassing privilege bits.

The design fault spectre exploits is sharing the branch predictor between different processes. Spectre *doesn't* depend on bypassing privilege bits. Spectre attacks trick the processor into accessing privileged memory from within a privileged process, by speculatively branching to snippets of the wrong code.