Slashdot Mirror
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.
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.
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
class action time!
I need one to pay for new MB for ones that don't get bios updates anymore.
I need one to pay for the lost of speed
supermicro I want an 1P EPYC board NOW! Intel is in deep and 2 AMD EPYC cpus is very over kill when 1 can hit the level of 2 intel ones.
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.
Does the issue only apply to CPUs newer than 5 years ago or did Intel just decide if your CPU is older than that they don't actually care? I'd previously heard anything since the original pentium up to the P4 was where it began.
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.
The flaw is concisely explained in this article.
https://spectreattack.com/spectre.pdf
In particular, it says the following.
I think we can safely say that if people haven't switched from XP by now, there's nothing in Meltdown or Spectre that'll change their minds.
-- Sometimes you have to turn the lights off in order to see.
They’re changing the microcode to provide a mechanism for the OS kernel to implement the fix. They work together.
Doesn't AMD have a hardware feature of encrypting RAM pages, which might mitigate exploits like this (one VM will only get garbage if it manages to access another VM's space, for example?)
Uh, why is Intel pretending like THEY are the ones deploying patches, Operating Systems, and fixes for their flaw?
I'm really confused.. Did our machines some how auto update the Intel hardware, or is this Intel taking credit for everyone elses effort to act like they were proactive?
Don't be confused. Intel is lying. As CERT just announced the only solution to this fix is to replace the processor. The software fixes are just workarounds that make it more difficult.
There's a proof of concept for Spectre written in Javascript, and would only be good for scanning the browser's memory for things like saved passwords.
That's not good, but it's in line with the quote, that the JS implementations of the exploits wouldn't be able to break out of the user's browser.
Try as I might, I can't see a way to exploit Meltdown with JS, as that requires being able to tell the browser to address memory it would never normally address. JS just doesn't have that capability.
You are not alone. This is not normal. None of this is normal.
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.
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.
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.
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).
It isn't possible. Intel is desperate to spin this story. There is no software solution to this flaw, but there are mitigation steps that can be done in software.
It's not yours!
Exactly. The article implies Intel released a microcode update that fixes the problem for 90% of its processors, but that couldn't be further from the truth. They've already determined that the problem can't be fixed with a microcode update. Instead, operating systems have to work around the problem.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
See some articles about Intel ME, Management Engine. Is Intel still providing hidden access, even if the computer is turned off but plugged in?
Unfortunately there are some things that won't change about it. Mainly the number of people that can't manage to understand what is going on.
Speaking of which, I have to go buy a few bottles of hard liquor before my mom hears about this on the news and phones me to ask about the bond villains (SPECTRE) that are trying to meltdown the worlds computers.
Meltdown cannot be fixed in microcode or software. There are already programs out there that exploit it. It affects all modern Intel processors. The fixes just mitigate the problem. You are talking about Spectre.
the fix will mitigate the threat... for the intel, the fix will clear the cache after any jump between kernel and userland, so it gives a big performance hit when that happen... there is no microcode that can solve this, its the hardware design in the intel that is broken, it only check if the branch is invalid AFTER loading it.
AMD is immune to the meltdown because the hardware detects the invalid branch BEFORE loading it
So without hardware change from intel, you will either have the full performance, but insecure system, or a secure system, but a big performance loss.
They may want to optimize, by avoiding the cache cleanup in some situations... but i'm not seeing any and if they exist, should be corner cases
Higuita
CPU microcode updates are in bios as well.
They might be "in" the BIOS in the most temporary sense as part of a firmware update but they are for the CPU which once verified will copy it into the CPU's ROM.
The confusion comes from the fact that microcode updates sometimes hitch a ride on a firmware update for the BIOS/UEFI that in turn passes the microcode update to the CPU. Alternatively the OS might get there first and obviate the BIOS patch (Macs are more likely to receive microcode via firmware update and PCs are more likely to receive it via an OS update long before the various hardware vendors get around to issuing a BIOS/UEFI update)
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
I think your mixing things up... this announcement is for microcode update, microcode is specific to a CPU, you can't apply an intel's CPU microcode to an AMD, they are implementation specific and cryptographically signed.
The AMD slowdowns are from kernel patches that do not discriminate between Intel and AMD, those patches are not from Intel they are efforts of kernel developers of the various major OS.
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.
A further thing to keep in mind: Spectre, the less serious but more widespread vulnerability, is most serious on Intel. In Google's tests using 3 proof-of-concept variants, one non-malicious and two non-malicious, only the non-malicious one worked universally while the malicious ones only worked problem free on Intel. One of the malicious ones did work on one of the two tested AMD parts, but only in a non-default configuration (while Intel was vulnerable in the default configuration as well).
"Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."
From what I can figure out, Spectre can only be mitigated against, it can't be eliminated without hardware design philosophy changes. It'll be very interesting to see the consequences of that.
You are not alone. This is not normal. None of this is normal.
amd ThreadRipper same thing no IPMI and no workstation boards.
The ThreadRipper Opteron 6300 is a socket G34 board.
NewEgg has Dual-Socket G34 boards, designed for workstations and server racks.
It can use an embedded KVM for remote management, which is an IPMI 2.0 compliant interface.
So... go vote with your wallet or something.
-- Sometimes you have to turn the lights off in order to see.
Red Hat just came out with a new kernel and microcode update.
Only three Intel processors have updates so far:
Family 6, model 63, stepping 2 (Xeon E5-1650)
Family 6, model 79, stepping 1 (i7 6950X)
Family 6, model 85, stepping 4 (i7 7820X)
Of course, more may be coming.
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.
That's where it gets dicey.
Some uCs have separate sections for 'outside entities'. They're still highly controlled.
- Vendor A sells a RTOS that is certified for ASIL-D.
- Vendor B uses Vendor A's product as middleware and certifies it to ASIL-C.
- Vendor C buys Vendor B's middle ware and makes a crappy infotainment system that isn't certified.
Can Vendor C now read/write anything in Vendor A's ring of trust?
How can it copy anything into ROM?
Which was the first out of order x86 processor in ~1995-1996, along with the changes to support bios updatable microcode (the pentium and possibly 486s had microcode, but it was supposedly not updatable. There were mentions that at least some pentium cores might have had an undocumented microcode update mode after either the fdiv or f00f bug, but I haven't found corroboration of that rumor.)
As a result every Intel processor and operating system since the mid 90s is susceptible to these two flaws
No, that does not follow. The CPUs released before the speculative execution became part of the pipeline processing would not be affected. That means that anything before P4 Willamette is likely unaffected (plus PIII and mobile versions based on the PIII pipeline even if released after the P4).
So how bad a threat is this if just decide to forgo the patch and run naked? I don't run crapwear or download drivers from whatever source has them. All my games come from steam and almost all my other software comes from companies that I've been doing business with for years.
I read at +2. If your post doesn't reach that level I will not see or respond to it.
Do we have a list of hardware that is good?
I read at +2. If your post doesn't reach that level I will not see or respond to it.
The CPU has both Rom and Ram for microcode. Microcode updates change the Ram.
https://media.ccc.de/v/34c3-90...
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
With the FDIV Intel offered to replace CPUs free of charge and took a $475 million charge to fund it.
Yes, if by "offered" you mean "were scared into by threats of lawsuits from everyone and their mom"
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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).
This description is very misleading because it makes it sound like the two issues are similar when they very much are not.
Meltdown provides processes with access to memory contents they have no right to access.
Spectre is merely a side-channel timing attack. Similar issues have been known about for years exploiting static caches, hyper threading, branch prediction, DPA...etc. Spectre is little more than a PR smoke screen for Meltdown. The two are not in the same league and they don't deserve to be described as if they are close relatives.
That is true of older ARM devices. Nothing modern though. ARMs have been superscalar for a while.
This description is very misleading because it makes it sound like the two issues are similar when they very much are not.
No, they are. "Meltdown" should be considered a subset of the "Spectre" class of vulnerabilities.
While AMD is not vulnerable to Meltdown variants that can be mitigated with KPTI, they're still vulnerable to Meltdown variants that can manipulate the kernel into doing the speculative execution for them- as the Google PoC demonstrated, eBPF with JIT (though disabled by default).
Spectre is merely a side-channel timing attack. Similar issues have been known about for years exploiting static caches, hyper threading, branch prediction, DPA...etc. Spectre is little more than a PR smoke screen for Meltdown. The two are not in the same league and they don't deserve to be described as if they are close relatives.
They're both side-channel timing attacks. They both exploit a race condition between instruction retirement after a fault in a superscalar architecture. The difference is that AMDs execution units can't specifically leak the data, because their L1 caches store and honor privilege bits. However, if that speculative execution happens in the kernel context (eBPF JIT) then userspace can still pick up the side-channel leaked data, making even AMD vulnerable to a subset of Meltdown, itself a subset of Spectre. Clear?
They might decide to settle it by giving out free chips.
Naaah. The usual solution is to settle it by giving all the money to the lawyers and the users get a $20 off coupon toward the purchase of a new CPU.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
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.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
I loved the PowerPC arch. Right before apple switch away from the PowerPC I was looking at getting the next generation Mac with a PowerPC chip. Then they switched to intel a few months later and I just decided to stick with windows.
My Linux box is a aging FX-8350. I've also thought about replacing it with a more modern processor. Problem is that I can't justify it. The 8350 delivers everything I need it to do.
I read at +2. If your post doesn't reach that level I will not see or respond to it.