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.
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/
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.
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?)
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.
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.
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.
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.
If it can read memory it shouldn't be able to read, it can potentially read things like credentials and private keys.
There are potentially some pretty severe issues with that even for 'typical desktop users'.
Well... about about an attack in JS to read your lastpass vault? Seems significant enough to the average user to be concerned.
-Unresolved symbol? Byte me!
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
It would slow down code, may be by as much as 30%.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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).
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.
If you know the internals of the browser you are running in, you can try to fetch addresses from fields. Think about it, javascript does pass references around. If you know enough to know where a variable holding an address is stored in comparison to some array that is embedded before it, you can try and go out of that array. Is it possible? I dont know, but are you sure it is not?
Avantgarde Hebrew science fiction
They can't disable speculative executions. That would take us back to the stone age.
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?
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.
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??
while spectre fix aren't released yet, it should have simple workarounds (compared with the meltdown) that screw the timings and make THIS side channel attack lot harder if not impossible... what may haunt you is that there may exists OTHER methods of doing the side channel attacks, as the info is still there
Higuita
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
Yes, you can read from those pointers, but you can't write to those pointers. Both exploits are read-only, they're about trying to extract data from somewhere you shouldn't be able to. But they're still bound by the limits of where the browser is going to allocate JS objects, which is not, obviously, going to be kernel memory.
You are not alone. This is not normal. None of this is normal.
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.
Sprectre fix is still not public, only the meltdown is!
The meltdown fix (isolate the kernel and userland ram and flush the cache on switcthing) is knows because it was merged in the linux kernel... all OS should do a similar fix to the linux and this fix should be final.
the spectre, should be adding some random delays and some more checks, so it's hard to impossible to abuse it... but the data is still in the cache, so there might exist other calls/methods that may also need those delays and checks... that is why it may haunt you, as later someone may discover another method of doing the same side channel attack
Higuita
exactly... but even desktop users... they can read private keys, passwords, authentication cookies, credit card info... anything that is stores in memory for each process. browsers are probably the most dangerous target here right now... and anything that may load plugins or external code
Higuita
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.
Forget about Spectre. Meltdown is an Intel flaw that cannot be fixed without replacing the processor.
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.
Even the Koreans haven't - looks like the "Hot Line" uses XP: http://www.bbc.co.uk/news/worl...
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?
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
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/
does that redhat update slow down AMD as well? or they are flagging AMD as safe?
I'm not sure, because that would be the kernel code, not the microcode.
The kernel config differences are these three added flags:
CONFIG_KAISER=y
CONFIG_SPEC_CTRL=y
CONFIG_ARCH_SPEC_CTRL=y
That might imply that they check for the arch before applying the spectre patches, but apply the KPTI fixes across the board.
128 PCI-E = kick ass pci-e storage system with lot's of pci-e to drive to high speed networking.
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;
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.
It's what Intel guys said on their conference call yesterday. I have not independently verified whether it's true.
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;
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.
Unless I'm misunderstanding it, the Javascript PoC in the paper can read arbitrary memory offsets. The JS is approximately this:
if (index < simpleByteArray.length) {
index = simpleByteArray[index];
index = (index * TABLE1_STRIDE) & (TABLE1_BYTES-1);
localJunk ^= probeTable[index];
}
and the JIT will compile the second line of that to:
REX.W leaq rsi,[r12+rdx*1] ; Set rsi=r12+rdx=addr of first byte in simpleByteArray
movzxbl rsi,[rsi+r15*1] ; Read byte from address rsi+r15 (= base address+index)
The base address is constrained by wherever the browser decided to allocate simpleByteArray, but index is fully under attacker control so they can pick whatever memory address they like, which of course includes the addresses that the kernel is mapped into.
I think this is still technically within the bounds of the original quote, because this only gives you the ability to read the entire contents of RAM. You can't write to it, and your own code is still stuck executing inside the browser sandbox.
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.
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.
No, don't forget about Spectre. Spectre is the stuff of nightmares.
Meltdown can be avoided by the OS. Spectre can't.
The only mitigation I can see for spectre is to recompile everything without using *any* indirect branch instructions. And that includes "ret", which would require redefining how C calling conventions work, breaking *every* platform ABI.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
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?
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.
Only on Intel processors , the read cannot happen on AMD. This is exactly why AMD told the researchers to go fly a kite. In more than 6 months they were only able to get the exploit to work on Intel processors to actually read kernel space. AMD kept telling them that their CPUs check the read before executing , so nothing is ever loaded from memory. So the big problem they are hyping up is basically useless on AMD CPUs.
The part where "arbitrary process memory" includes the kernel is indeed Intel-only, yes. The discussion was about exploiting Meltdown from JS, after all, not Spectre. If you only target user address space then the reads will complete just fine on AMD.
It's also possible to extract data from a different process by finding code in that process that can be used to leak data. That part of Spectre works fine on AMD too, and I see no reason why the process in question couldn't be the kernel (even AMD's processors allow kernel code to read kernel address space, after all). I think that variant would be very difficult to exploit from Javascript, however.
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
Intels updates also slow down AMD chips that don't have the bug as well.
Why? Out of spite...?
No sig today...
What operating system should developers of applications be using instead? FreeBSD?
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!
No it wouldn't. The original Atom didn't have speculative execution. Therefore, we'd only be back at the atomic age.