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
I want it back
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.
Since XP is not running on hardware made in the last five years, the remaining 5.18% on XP will now face a truly unpatched world, not by Microsoft, not by Intel and soon not by Mozilla who's 52 ESR will end of life soon. Will people finally upgrade, or will we face massive botnets from XP zombies.
Aside from games I have a little virtual lab at home running on VM Ware. That and some Virtual Box VMs and a couple Virtual PC ones under Win 7. I'm hoping this doesn't tank my guest' OSes performance. I just upgraded to an i5-7500 and my bro got an i7-4690k last year.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Intel patching stuff to fix implies microcode updates, but that's not the case here. Aren't these fixes from OS vendors, and the chips are still flawed? I suppose Intel could be helping the OS vendors though.
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.
"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."
yeah, all you have to do is rewrite all software to avoid using system calls and the performance problem goes away
The article says that Intel is releasing patches for processors up to five years old. That would suggest that they're going as far back as Haswell. It would have been nice if they were a little more specific as to where the line is drawn.
I assume these patches are being released in the form of microcode updates that will be pushed out to end-users in the form of system BIOS updates. My worry is that we're going to see the Android-effect where older motherboard manufacturers will simply refuse to provide updates, even though Intel is handing them the code. As example, my H97 motherboard from Gigabyte hasn't seen a BIOS update since Q3-2015. I'm not holding my breath that I'll see a fix.
Something to keep in mind with the biggest cloud providers. They design their own servers, and they're big enough for Intel to customize their CPUs.
http://www.datacenterknowledge.com/archives/2014/11/13/intel-designs-custom-aws-cpu-for-fastest-ec2-instances-ever
"For typical desktop users, the risk is arguably less significant. While both Meltdown and Spectre can have value in expanding the scope of an existing flaw, neither one is sufficient on its own to, for example, break out of a Web browser."
From here: https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfixable-security-flaws/
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?)
I've heard that the newest Intel CPUs weren't hit as bad. I'm wondering how my i5-7500, i5-4560 and my brother's i7-4690k are going to fair...
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Can’t the kernel just hide the password handling and crypto stuff in a separate address space and use the regular method for the boring stuff? Then cache-flushing would only need to happen sometimes rather than every time. Aren’t some big parts of the kernel “who cares if this data is exposed”?
I’m asking because I don’t know.
Fix your keyboard settings.
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?
It would seem the all-but-dead Itanium processor is not vulnerable to these attacks. Fancy that.
No as "spectre" makes the victim process access data and expose that to the attacker.
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.
Wasn't fixable without a hardware upgrade?
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.
From what I understand, OSes can update themselves to protect from this bug, and it is also a very low level bug that cannot be fixed easily. How is this possible?
Also, if intel can update processor firmware that easily, what prevents malware from doing the same?
Avantgarde Hebrew science fiction
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).
Can Intel update my computer without me knowing.
of your Mobo manufacturer and/or system builder? I've got a newish Asus board for my i5 7500 but my 4560's board is pretty long in the tooth. I'm not expecting updates at this point...
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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.
Your keyboard has syphilis and is about to fall off too?
Misleading article title. Intel can't patch existing processors. Intel's PARTNERS are patching it. Not Intel.
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
Nothing new. Intel has been known to employ dirty tricks to slow down AMD chips.
that encrypted RAM pages protect you from someone physically accessing the RAM and steal the data... it is a known weakness for all the hardware and only encrypting the RAM directly protect that.
Higuita
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;
Nice excuse to force all your customers to install a binary blob on their cpus. Should we be surprised when this obfuscates access to their management engine.
It isn't possible
Unless the prediction pipe can be patched in microcode. The prediction pipe uses a program stored within static memory inside the processor to try and predict the results based on cached previous runs in low level memory. The Spectre flaw requires training that pipe to pick the wrong answers in a "known" way and to do so in a very specific manner. I'm pretty sure that if Intel came out with a way to fix this, it would be to make the prediction less predicable to anything outside of that specific core and make some of the timing a bit more random perhaps by inserting random nop within the microcode program. Exploiting with spectre is a lot of dominoes lining up just perfectly and in a controlled experiment that's doable. Unsure of how easily it can be done on an actual production machine, especially if a process isn't locked to a specific core within the chip. Each core has it's own pipe for predictions, so if a program is being flopped around machines, there's less likely a chance that the program can successfully train the core incorrectly before the cache is flushed.
However, I don't know any of the deep internals into Intel's chips so it might just be them spinning, who knows.
See some articles about Intel ME, Management Engine. Is Intel still providing hidden access, even if the computer is turned off but plugged in?
AMD needs desktop class server chips like intel-e3.
The amd ryzen boards can do ECC but none have IPMI and most are to much gamer based.
amd ThreadRipper same thing no IPMI and no workstation boards.
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.
Does anyone know how this is going to affect the embedded world?
For next generation hardware we're looking at consolidating embedded PPC, 68k, PIC, etc to ARM.
I would think no anyway. My understanding is that the exploit derives information from the processor cache, where data has already been decrypted by the memory controller on load.
Not really. Intel makes a microcode patch and gives it to the OS vendors, they integrate it into the OS and install it. So you might not actually see it being installed because Microsoft/Apple might not make a big deal about it, but it's not some secret back door. Linux usually posts one line in the boot log, something like "updating CPU microcode" and that's all. It's a transparent process that takes a fraction of a second.
If you're worried about some malware getting into the channel, every patch has to be signed by the CPU maker and is verified by the CPU itself, so while it's not impossible, it's certainly not easy. Intel, hopefully, keeps the signing keys on a CD-ROM in a vault somewhere, with a special networkless computer only used for doing the signing process. Or at least they should, because it's something of a "keys to the kingdom" type thing.
One thing about CPU microcode is that it's temporary. Every time you turn off the power, it has to be reinstalled. So there's no chance of a bad patch bricking your pc. Worst case scenario is reboot into safe mode.
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.
CPU microcode updates are in bios as well.
*NEW was just comeing soon! any links?? Like a few days ago.
Did they rush this out??
If you have control over the firmware (whether while(1) or RTOS) and, especially if you have cryptographic verification or authentication (if you're a slave to a host), you have nothing to worry about. If you're running apps/hosting processes that are installed by outside entities, that's where you'd have concern.
sig: sauer
It will only be a Tinfoil Code Update (TCU).
Intel pushes a microcode blob out to OSes and board/system vendors.
Those OSes and board/system vendors pull in the blob and issue updates that include them.
Some platforms allow the OS to update microcode at run time, others (particularly most server platforms) forbid microcode updates by the OS and must be applied by firmware.
Either way, the firmware installs some microcode at every boot, then the OS may or may not follow up with an update, so any microcode updates for any platform will appear in both places.
XML is like violence. If it doesn't solve the problem, use more.
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.
Intel CPU hardware check if the code branch is invalid AFTER it is loaded to the cache.
AMD CPU hardware check if the code branch is invalid BEFORE it gets loaded to the cache
you can not move a hardware part in software, AMD build it right, intel build it wrong and can't be fixed without replacing the hardware. The workaround requires that the cache is clear every time that the kernel switch to to userland, and without the cache you fix the problem, but also have to reload all the userland code from RAM... just to be throw away next time the app calls the kernel
Higuita
This is how the OS update works. How come intel are saying this is their update?
Avantgarde Hebrew science fiction
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?
Fucking brilliant.
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, as well as all of ARM's recent 'performance' cores, which thankfully do not include any of the major single board computers, like the Raspberry Pi, Pine A64, Rock64, Orange/Banana Pis, etc. Higher Performance Qualcomm, Samsung, etc chips utilizing the higher clocked cores are generally OoO and thus affected. Basically all other arm chips are In-Order. Furthermore, this shouldn't affect original Intel Atom chips. Most of them were In order, and either didn't have branch prediction or didn't have the combination of branch prediction and code reordering necessary to allow this exploit to work, so those chips are safe as well (however still susceptible to rowhammer on DDR3 capable SoCs/chipsets.) Newer Atoms are actually out of order processors and thus have the same concerns as PPro/Netburst(P4) derivatives.
Thankfully this isn't quite as widespread a threat as first depicted, but is widespread enough on x86 and arm to hopefully raise awareness among the general populace about why technological monocultures like x86/arm are dangerous and will help re-establish cost effective alternative platforms in the near future.
Intel's reign as a tech king has been declining for years, but this will likely be the nail placed in its coffin, especially with the Taiwanese VIA and their joint venture with Shenzen (IE China) to produce their own internally developed and licensed x86 cores thanks to VIA's continuing license to the x86/x86_64 ISA (albeit without access to Intel or AMD motherboard interfaces/interconnect busses. So no return to the heydays of the S7/SS7 everybody works on everybody else's chipsets :(
So yes, unless Intel releases microcode updates which help with older chips, a huge swath of processors will be 'defective by design'. Honestly at this point they should just be compelled to provide the microcode signing key for those older processors as well as processor documentation so that end users can 'service' the microcode themselves. Maybe someone can get that added to the class action that will inevitably result from this FUBAR situation and even if nobody gets a worthwhile cash settlement, at least something useful will be released as part of the settlement. If the same could be done for older Intel ME implementations, that would be a huge bonus.
To someone further down: Besides your i7-860 being susceptible to this issue, your motherboard chipset also has an XAPIC2 glitch in it that affects your IOMMU/VTd security, so you have a double whammy of unfixable security bugs. Given the lack of 64 bit BAR support it doesn't really matter though since you can't properly use either Xeon Phis or modern AMD GPUs on it for GPGPU purposes as a result of those shortcomings, which require either FM2, AM4, or 2011/1151 (1150?) chipsets to gain the required PCI BAR support for OpenCL on RX or later chipsets or the ROCm GPGPU software/driver platform.
Socket G34 is not ThreadRipper or ZEN they DDR 4 that linked one is DDR3
does that redhat update slow down AMD as well? or they are flagging AMD as safe?
When you think this sort of thing has been a potential target for a decade or more. The facts remain nothing is out there in the wild and in a couple days its back to normal no harm or foul. In fact a couple people doing speed tests prior and after the Windows patch appear to show very little slowdown within a margin of error. Well I guess the tech news is a bit boring these days so a good "sky is falling" story was welcome news for the tech world.
in the next computer you buy?
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
At least this way there's some monetary punishment for Intel. Maybe a lot if it can be shown they were aware of the defect for an extended period of time. Personally I'd rather see tighter regulation around warranties and fitness for purpose. If this knocks 5% off my processor that's the equivalent of it taking me down to the next cheaper model. That's around a $50 cost to me as a consumer.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
This affects cloud folks more, since they share VMs.
Dedicated servers, owned by the same people would have mitigated this, since it is unlikely a corp would hack it's own servers, and if full data separation is necessary, simply purchase another server and firewall it off.
But of course, your data is safe in the cloud. Aggregated with everyone else's data, running on a computer owned by someone else, and upgraded at their whims.
128 PCI-E = kick ass pci-e storage system with lot's of pci-e to drive to high speed networking.
The opteron 6300 series aren't threadrippers, they're abu dhabi from 2014.
I wonder what would happen if people with socketed CPUs launched a class action lawsuit demanding a replacement?
With the FDIV Intel offered to replace CPUs free of charge and took a $475 million charge to fund it.
https://en.wikipedia.org/wiki/...
On December 20, 1994, Intel offered to replace all flawed Pentium processors on the basis of request, in response to mounting public pressure. Although it turned out that only a small fraction of Pentium owners bothered to get their chips replaced, the financial impact on the company was significant. On January 17, 1995, Intel announced "a pre-tax charge of $475 million against earnings, ostensibly the total cost associated with replacement of the flawed processors." Some of the defective chips were later turned into key rings by Intel.
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;
That is not a thread ripper, it's the old bulldozer tech.
^^^^^This is exactly what Intel is trying to obfuscate^^^^^^
They are creating as much FUD, smoke and mirrors as possible in order obscure this very important fact.
Are you sure this is a microcode update? Nowhere in TFA does it mention that. From what I understand, this is an OS patch that is preventing the Meltdown bug from being an issue, but at a 5-30% performance penalty.
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.
Mainframes in which security is important (unlike mainstream processors) don't suffer these kind of issues.
ARM is largely immune to Meltdown and Spectre. Both attacks require out-of-order execution; most ARM CPUs are strictly in-order devices.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
Well yeah. That's why I think joining a class action lawsuit might be a good idea. They might decide to settle it by giving out free chips.
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;
Speculation about the slowdown...nobody in the outside world really knows yet.
Is it possible?
How big would be the performance hit?
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.
wrong thread maybe?! :D
Higuita
If you have a quadcore processor, would it be possible to run the kernel and nothing else on 1 core, and use the other 3 cores for user programs?
Would the above prevent user programs to access kernel memory that shouldn't be accessible to user programs?
Based on my understanding the specific Meltdown hole can be plugged with KPTI. It's really just a matter of removing the kernel TLB entries whenever executing user code.
Lawyers are the carriers of force in the American system, rather like virtual photons in QED.
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;
I don't see how else they could "expect to have patched 90 percent of its processors", Intel doesn't control all kernels ever. It's also what everyone else is talking about in response to this announcement. A microcode patch from intel was expected... what wasn't known is how much could be fixed in microcode, and as it turns out - not all of it, that's why we still have the OS specific kernel patches.
I get it
The CPU design fix for spectre should actually be quite simple; swap out branch prediction state with thread context switches. But impossible to retrofit via microcode updates.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indi- cating that out-of-order execution generally occurs and instructions past illegal memory accesses are also per- formed.
https://meltdownattack.com/meltdown.pdf
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.
True - this is not a microcode fix. Intel doesn't have a processor in or even ready for production that dodges the flaws even to the extent AMD does. AMD isn't completely in the clear - they may not have Meltdown vulnerability (absent a non-default setting), but as with ALL modern processors (since at least Pentium Pro on the Intel side) they are at least in part vulnerable to Spectre. Spectre vulnerability is inherent in the way all modern processors work. Speculative execution has been in all Intel processors since at least the Pentium Pro. HOWEVER, Intel is treating this as Not-A-Bug for the processors because the processors are operating as designed; their releases mitigate but don't eliminate the problem, and have a large performance impact on any but the most recent generations (which have partial mitigation in the hardware). Bottom line: if you want to avoid the Meltdown bug with minimal performance hit now, get AMD and run it in a default CPU configuration.
Also, Intel is only providing mitigation for processors less than 5 years old so there's a huge universe of older stuff out there that runs Windows and Linux just fine (for now - expect MS to at least think about cutting off all Windows support for Intel CPUs over 5 years old due to this, rather than patching and living with the performance gripes) but will never be patched with performance in mind. The o/s vendors might provide patches that work for the security/privacy issue but they will crater the performance of older gear forcing mass hardware upgrades. The cynic in me immediately conjures conspiracy theories about people not buying new computers often enough. I'm in that position. And the replacement hardware (which was not in my budget; that will also require some work) will definitely be AMD-based. Though with nVidia graphics...
The outing of this debacle is really punishment from three-letter agencies due to Intel's backpedaling on the management engine backdoor because of all the bad press.
My hunch is that this vulnerability has been around for a long time inside of 3-letter agency circles. This is doing exactly what a perfected threat from a three-letter agency would look like.
1. Plausibly deniable. (Just design issues)
2. Massively negative public backlash.
3. Regulatory punishments coming as well.
4. AMD who were less public about their back door are less affected, but slapped with spectre to ensure they toe the line. Also this makes it less obvious that everyone moving to the backdoored AMD was the plan all along since "AMD is effected too!".
Something to me does not feel right about this. Whether I'm correct or not about the reasons is irrelevant, something is amiss here.
I'm wondering how far back they will really go. 5 years ago my CPU was still on sale (i7 2700k) and is still a pretty good processor. I have no desire to upgrade, especially as that means a new motherboard etc.
5 years is rather short for a CPU.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
From my comment.
...previous runs in low level memory. The Spectre flaw requires training...
Yeah, that's what I was talking about. My bad if I didn't make that clear enough.
Indeed it is. I think most of my systems are past that date, and work just fine:
grep -m2 -E 'name|bogomips' /proc/cpuinfo
model name : Intel(R) Pentium(R) III CPU family 1133MHz
bogomips : 2379.88
model name : Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
bogomips : 5000.22
model name : Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz
bogomips : 6584.89
model name : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
bogomips : 4191.52
Only the latter is within the five year mark.
Even the PIII is more than fast enough to handle smtp/dns/dhcp and other services without breaking a sweat, and is frugal enough to not even need a CPU fan. What benefit would I have by replacing it with something that's going to use 8x as much electricity doing nothing more?
While that may be an exception, it's not uncommon for companies to have a longer lifecycle for servers than five years.
Would people be pleased with a car or boiler that needs replacing every five years?
This looks like it's been updated since then:
http://www.kb.cert.org/vuls/id...
Previously, solutions were "Replace CPU" or "Apply updates". Now it's just "Apply updates"
Tell that to the AWS customers who got reamed after the patching back in December.
Would people be pleased with a car or boiler that needs replacing every five years?
Haven't been keeping up on what's going on with the home appliances scene lately, have you? It's to the point where people feel lucky if one of these abominations lasts five years.
Simple Meltdown attacks run within your own attacking process, bypassing privilege bits.
Simple Meltdown attacks run within your own attacking process, *because* the privilege bits can be bypassed.
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.
That is correct. Meltdown also uses faulty branch predictor behavior to widen the window with which the side-channel is open to improper reading. Only Intel processors allow this to happen across privilege boundaries.
And Spectre's (variant b) branch predictor tomfoolery is just to pre-load the cache. The data is read from the cache. That is the side-channel. These are 3 variants of the same problem- cache leakage side-channel that can be read utilizing common behaviors of superscalar architectures.
Unsure where we're miscommunicating.
You know when PC gamers make fun of old computers and software as outdated? Giving Linux Luddite users crap? Welcome back to the early 2000s bitches. I bet you wished you would have payed more attention to our crazy ramblings. (As he plays Kodi, emulators, web browsing, etc. on his 2010 32-bit 1GB RAM netbook on a large monitor just fine). This is why you use gaming consoles for GAMES and desktops for WORK. I am very curious of the GPU effects of the updates.
No, they are
Yes they are.
Get off the pot you fucking idiot. None of what you wrote made any sense.
From what I gather it is a combination of a microcode update to fix Spectre, and an OS update to mitigate Meltdown. In either case Intel has had a hand in developing both fixes. Also msmash's mashup of the summary didn't help. Intel isn't issuing anything to customers but rather is providing patches and code to vendors. e.g. Linux's KPTI was mostly written by Intel engineers (which is why AMD got upset when they realised it and issued a patch against KPTI so it doesn't also gimp performance on their hardware.
90% of affected processors? what's an average user?
Intels updates (microcode) doesn't run on AMD. Intel doesn't issue patches for OS.
Custom electronics and digital signage for your business: www.evcircuits.com
That was a single chip in 1995, we now have orders of magnitude more chips produced per year. Even if Intel did decide to give out unaffected models, it would take ~3 years to set up the lines and ~2 years at peak production to replace just half of them.
Custom electronics and digital signage for your business: www.evcircuits.com
Found the intel shill. The code was contributed by intel. Even if linux et all needs to approve it first it was still written by intel hoping that it wouldnt get noticed that it slows down amd as well. Luckily it failed and AMD picked up on it.
Also in case you have forgotten intel of all companies contributes the most code to the linux kernel. Stop trying to pretend intel didnt write that code to sabotage the perforrmance of amd processors.
Intels updates also slow down AMD chips that don't have the bug as well.
Why? Out of spite...?
No sig today...
You are the one being highly misleading. The kernal patch was written by intel and submitted to the linux team for approval. AMD then picked up the shennigans and submitted a alteration to the code to exclude AMD processors from the slowdown. You can't call AMDs code a patch and at the same time try to argue Intel's isn't and try to palm it off on the Linux team. You are the one being highly misleading here.
"Programmers paid by Intel may or may not have contributed code to the patch, but regardless, "
No, you are playing down this bit too. intel DID submit the code and that is the important bit. Intel IS the biggest contributor to the linux kernel.
"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."
Bullshit. If you break things for the competitor which did not require fixing then you can get sued for it.
As a percentage of their production, the numbers are similar.
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;
Low end embedded processors (including the ARM Cortex-M series) don't do speculative execution, so there should be no vulnerability. Nor does the low end of the Cortex-A series. Unless you're embedding high end ARM processors you're safe for now.
The problem is that there is nothing to replace the CPU with. All current high end CPUs have some degree of vulnerability to these attacks.
This problem could cost Intel a LOT more money. There is a much larger number of affected CPUs; it's just about everything they make rather than just a small part of their production, and the market has also grown in the intervening years.
There is also the labor cost of replacing the CPUs. The Pentium problem only affected desktop CPUs and that was back when they were fairly easy to change, so Intel could just mail out the parts and expect users to install them. Now a lot of the systems are laptops with CPUs that are soldered to the motherboard; it takes specialized equipment to replace those, and laptops are a lot harder to take apart than desktop systems are.
Finally, it's likely that a much larger percentage of the affected systems would get repaired. The FDIV bug didn't have any effect on the vast majority of computer users; fixing it was really only important to people who were doing scientific computing or serious mathematical analysis. Computer security is an issue for EVERYBODY.
Yeah, I think they should have to replace the Core(TM) i5-3210M in my ageing Macbook Pro.
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;
The SPECTRE bug affects every cpu that uses speculative execution. That means just about everything from the 1995 Pentium-Pro onwards. The only exception is the first generation Intel Atoms (32-bit-only Bonnelle series) which did not have speculative execution.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
So it seems like the aliens in "Independence day" haven't patched their processors properly. On the serious side: most incredible shit that Hollywood has pulled off, ever. Aside from some 64567 of other films.
"It is no measure of health to be well adjusted to a profoundly sick society." - Jiddu Krishnamurti
Apple never should have left PowerPC!
Maybe a non Evil ME version or one we can turn off?!?!?!