By Next Week, Intel Expects To Issue Updates To More Than 90% of Processor Products Introduced Within Past Five Years (intel.com) 289
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 (Score:5, Interesting)
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
Re:Intels updates also slow down AMD chips that do (Score:5, Informative)
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.
Re: (Score:3)
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?)
Re: (Score:2)
No as "spectre" makes the victim process access data and expose that to the attacker.
Re:Intels updates also slow down AMD chips that do (Score:5, Informative)
The AMD scheme does AES-128 on the fly when reading anything from DRAM (!)
https://lwn.net/Articles/69982... [lwn.net]
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... [exploit-db.com]
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.
Re: (Score:2)
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.
Re: Intels updates also slow down AMD chips that d (Score:5, Informative)
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).
Comment removed (Score:5, Interesting)
Re:Intels updates also slow down AMD chips that do (Score:5, Funny)
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.
Re: (Score:2)
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.
Re: (Score:3)
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?
Re: (Score:3)
Re:Intels updates also slow down AMD chips that do (Score:5, Interesting)
Re:Intels updates also slow down AMD chips that do (Score:5, Insightful)
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.
Re:Intels updates also slow down AMD chips that do (Score:4, Insightful)
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?
Re:Intels updates also slow down AMD chips that do (Score:4, Informative)
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.
Re:Intels updates also slow down AMD chips that do (Score:5, Informative)
Intels updates also slow down AMD chips that don't have the bug as well. And AMD had to come out with there own update to back off the big slow down fix that Intel patch
This is both somewhat true and highly misleading. The team that releases the Linux kernel, headed by Linus, created a patch to address the issue. Programmers paid by Intel may or may not have contributed code to the patch, but regardless, accepting or rejecting their contribution was up to Linux and the normal kernel team. The original patch did not distinguish between AMD and Intel chips, but it was not in any sense an "Intel update." It was just a change to the way the kernel operates which mitigated the bug but also introduced some performance penalties. AMD programmers then provided another patch that bypassed the mitigation patch on AMD processors to avoid the performance penalties. This is standard procedure for not only the Linux kernel but most large software projects. Fix the vulnerability for everyone, then look at whitelisting situations which do not require the fix.
Re: (Score:2, Informative)
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
Re: (Score:3)
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.
Re: (Score:3)
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.
Re:Intels updates also slow down AMD chips that do (Score:5, Informative)
Solution
Replace CPU hardware
The underlying vulnerability is primarily caused by CPU architecture design choices. Fully removing the vulnerability requires replacing vulnerable CPU hardware.
Re: (Score:3)
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"
Re: (Score:3)
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.
Re: (Score:3)
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.
CPU microcode updates are in bios as well. (Score:2)
CPU microcode updates are in bios as well.
Re: (Score:3)
CPU microcode updates are in bios as well.
They might be "in" the BIOS in the most temporary sense as part of a firmware update but they are for the CPU which once verified will copy it into the CPU's ROM.
The confusion comes from the fact that microcode updates sometimes hitch a ride on a firmware update for the BIOS/UEFI that in turn passes the microcode update to the CPU. Alternatively the OS might get there first and obviate the BIOS patch (Macs are more likely to receive microcode via firmware update and PCs are more likely to receive it via an
Re: (Score:3)
The CPU has both Rom and Ram for microcode. Microcode updates change the Ram.
https://media.ccc.de/v/34c3-90... [media.ccc.de]
class action time! (Score:3)
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
Re:class action time! (Score:5, Interesting)
You'll get a $2 off coupon for a new CPU. $100 million for the lawyers
Re:class action time! (Score:5, Insightful)
supermicro I want an 1P EPYC board NOW! (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
they just have an gigabyte one with on board SFP+
The Tyan one not at newegg has only dual gig-e and to use pci-e you need OCP LAN Mezzanine or an PCIe x24 riser card that gives a slot.
Re: (Score:2)
Gigabyte: http://b2b.gigabyte.com/Server... [gigabyte.com]
Newegg: https://www.newegg.com/Product... [newegg.com]
Re: (Score:2)
I'll NEVER buy supermicro again. learned my lesson.
brand new server mobo, could not update bios, even ipmi runs fine but they don't let you do bios over ipmi unless you pay MORE. I wanted to but my store could not figure out how to sell that option to me!
mobo went back to shop since it went into a boot loop. its been OVER A MONTH NOW (more like two months) and still not fixed.
note, I bought this at central computers in mtn view (which I now have to say, gave me really shitty service and could not care le
Re: (Score:2)
Um they have 3 of them https://www.supermicro.com/Apl... [supermicro.com] for example. You can get them in a 1ru supermicro chassis for about 1500 for a functional computer.
*NEW was just comeing soon! (Score:2)
*NEW was just comeing soon! any links?? Like a few days ago.
Did they rush this out??
Marketing (Score:3, Informative)
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.
Intel ME? Is Intel still providing hidden access? (Score:3)
Re: (Score:3)
VxWorks without the VxVMI option doesn't have any memory protection at all. So a VxWorks system is unaffected by this bug!
You might want to get yourself a strong coffee and pay attention in code reviews though.
5 Years? (Score:4, Insightful)
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.
Re: (Score:3)
It affects much older CPUs, but anything older than 5 years is EOL and not supported.
I am one of the most Intel Fanboi's here (just look at my post history) and even I can't absolve any of this, other than I can accept the flaw is so old no one thought about it in modern CPUs... but now that it's discovered it needs to be handled like the FDIV bug: uC patch what can be patched with no or trivial (less than 2%) performance issue. If it can't be patched it needs to be replaced.
Not sure how to handle the EOL
Re: (Score:2, Insightful)
They really should update everything, but maybe they're just starting with the newer ones.
Failing that, they should at least go back to Conroe, which was pretty much their first CPU that would actually be useful in 64-bit mode. It also means that there's a simple "core=fixed, pentium=vulnerable" understanding for users. But Nehalem was probably the first CPU that was regularly used with more than 4GB of RAM. Any of those would be, in some way, acceptable, but only going back to Haswell is just going to enco
Re: (Score:3)
myself included...
Re: (Score:3)
My gaming computer is still a Nehalem i7 860 with 16GB RAM. It's had a couple of video card upgrades, but the CPU has been good enough up until now.
I've been hoping it would hold on until the Ryzen 2 is released, but I have no brand loyalty (recently I've built machines for people using both Ryzen and Coffee Lake). The way this gets handled by the manufacturers will feed into my decision strongly.
Re: (Score:3)
but only going back to Haswell is just going to encourage a lot of people to buy new CPUs. From AMD.
Indeed, that is my personal conclusion, unless they go back further with the microcode, no more Intel for me.
Re: 5 Years? (Score:4, Interesting)
there is a technical issue here too...
We switched source repositories from ClearCase to Perforce around 5 years ago...
I think that while you're right that EOL shouldn't be an excuse, there may be serious issues to resurrecting the older codebase...
hence why I suggested similar spec new CPUs and MBs at cost as an option.
Re: (Score:2)
I doubt it's so much that Intel doesn't care about hardware older than 5 years, so much as they're prioritizing newer hardware. (Supporting older hardware rapidly reaches the point of diminishing returns).
I'm pretty sure my 2007-era Core2 MacBook will never see a fix from Apple or Intel. I could probably "get" a patched OS on it by switching to Linux... but it's easier for me to put the MacBook out to pasture and use my Raspberry Pi 3 instead.
Re: (Score:2)
5 years?! no, everything above and including pentium 4 should be vulnerable... so that excludes the all the XXX86, iX86, pentium, pentium 2, pentum III ... and of course, itanium... or maybe not, probably that one is also vulnerable, but no one cares...
Re: (Score:3)
Which was the first out of order x86 processor in ~1995-1996, along with the changes to support bios updatable microcode (the pentium and possibly 486s had microcode, but it was supposedly not updatable. There were mentions that at least some pentium cores might have had an undocumented microcode update mode after either the fdiv or f00f bug, but I haven't found corroboration of that rumor.)
As a result every Intel processor and operating system since the mid 90s is susceptible to these two flaws
No, that does not follow. The CPUs released before the speculative execution became part of the pipeline processing would not be affected. That means that anything before P4 Willamette is likely unaffected (plus PIII and mobile versions based on the PIII pipeline even if released after the P4).
Anyone benchmark Gaming & VM speeds? (Score:2)
Re: (Score:2)
Phoronix did a few benchmarks on games [phoronix.com]
Of course, each game is a different animal, but it looks like there may be reason to hope that games aren't heavily affected.
Thanks, Those are 8700ks though... (Score:2)
Re: (Score:2)
The thing to look for is "PCID" instruction support. Intel CPU's without the PCID instruction are slowed more than those that have it.
I've done some looking at various machines at work, home, etc, and have found a Broadwell Xeon E3-1276 that has the PCID instruction but the older Ivy Bridge doesn't. (And I'm sure the PCID support also depends on the model of the CPU -- maybe Xeon has it while i7 doesn't)
The mitigations for the "Meltdown" bug affect context-switching most: So an application that hits the dis
Concise Summary Of The Flaw (Score:5, Informative)
The flaw is concisely explained in this article.
https://spectreattack.com/spectre.pdf [spectreattack.com]
In particular, it says the following.
Re: (Score:2)
Re: (Score:2)
1. Flaw found in infrastructure. Devs scramble for solution.
2. Devs find a way to fix this but the fix requires OS patching to mitigate the risk first, then the hardware needs an update.
3. Software players send out notifications they are doing Stuff and Things, OS vendors send out updates, people start rebooting servers.
4. Cloud vendors who control their hardware platform deploy CPU/BIOS level updates as they've already patched their systems at the Soft
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
the fix will mitigate the threat... for the intel, the fix will clear the cache after any jump between kernel and userland, so it gives a big performance hit when that happen... there is no microcode that can solve this, its the hardware design in the intel that is broken, it only check if the branch is invalid AFTER loading it.
AMD is immune to the meltdown because the hardware detects the invalid branch BEFORE loading it
So without hardware change from intel, you will either have the full performance, but i
Re: (Score:3)
So how bad a threat is this if just decide to forgo the patch and run naked? I don't run crapwear or download drivers from whatever source has them. All my games come from steam and almost all my other software comes from companies that I've been doing business with for years.
Re: (Score:2)
6. Asus, HP, Dell, IBM, Lenovo send out BIOS updates to consumers and business' to upgrade their BIOS with new microcode given to them by Intel which then assists in the patching done prior.
So are IBM Power and System z processors also affected by this bug . . . ?
Hey, this is almost like real hardware bugs we had in the good old days, when flies would short out the wiring in room sized computers.
Just hide the sensitive bits (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
It doesn’t (unless it does some of the gmail password handling somehow). It knows about its own internal sensitive data. I thought that was what was exposed.
Also, I was asking because I don’t know exactly how all this works. If you do, then maybe answer...? If you don’t, then maybe someone else will explain it to both of us.
Re: (Score:2)
The short story is that there is no fix to stop any process from reading the entire memory contents of the machine. You need to replace the Intel processor with processor that doesn't have this flaw to fix this problem.
Re: (Score:2)
Actually Google has a really good overview: https://googleprojectzero.blog... [blogspot.com]
Saw that. It needs an executive summary.
I can't find the answer to my question there. Even if I read it carefully, I don't know if it would have the answer.
The short story is that there is no fix to stop any process from reading the entire memory contents of the machine. You need to replace the Intel processor with processor that doesn't have this flaw to fix this problem.
Too many people are working on OS changes for that to be believable. If an OS change is irrelevant, then why bother implementing it?
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Do we have a list of hardware that is good?
Re: (Score:3)
I loved the PowerPC arch. Right before apple switch away from the PowerPC I was looking at getting the next generation Mac with a PowerPC chip. Then they switched to intel a few months later and I just decided to stick with windows.
My Linux box is a aging FX-8350. I've also thought about replacing it with a more modern processor. Problem is that I can't justify it. The 8350 delivers everything I need it to do.
Re: (Score:2)
Re: (Score:2)
Let's see... today I need to buy a Horse, Battery, and Staples. Correct.
https://xkcd.com/936/
That's my Alexa password. Every week I have to return 7 more horse batteries to Amazon.
Re: (Score:2)
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?
As soon as you start using these tricky approaches, security gets really hard. For an analogy, look at crypto: in theory you can make it secure, but in practice adding nice little (seemingly insignificant) features suddenly changes the attack surface in a way that makes side-channel attacks possible. Bruce Schneier thus says if you want security, you need to make it as absolutely simple as possible.
Another example: consider the mechanism of "root" and "userland." In concept, it is clear, but in practice t
Re: (Score:2)
This is a good answer, thanks. But...
Bruce Schneier thus says if you want security, you need to make it as absolutely simple as possible.
If the simple way is too slow, then you sometimes have to try something else less simple. I guess I don't believe it's impossible, but you've made the case that it's very difficult.
Even the openBSD team that is obsessive with security hasn't found a way to stop them.
There should be a way to mathematically prove a section of code is secure. If there is, then that would imply an answer exists. Perhaps it's too difficult or the result is even slower than the alternative too-slow implementation.
Uh what? (Score:5, Insightful)
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?
Re: (Score:2)
Re:Uh what? (Score:5, Insightful)
The Intel propaganda machine is working hard, just look at all sites that try to combine the two kind of exploits into one and imply that all processors not only Intel is vulnerable when in reality one type of exploit with less severity is general while the severe one is Intel specific.
But I have no doubt that Intel engineers are also working hard in order to patch the problems as quickly as possible and with as little performance impact as possible.
Can someone explain how will this be implemented? (Score:2)
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?
Re: (Score:3)
Re: (Score:2)
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
Re: (Score:3)
Doesn't this leave you at the mercy (Score:2)
orly (Score:2)
Paid Intel shills will mention 'spectre'... (Score:5, Informative)
There are PAID intel shills in this forum and on every other one across the net. Intel payolla outlets Anandtech, Tom's Hardware and Arstechnica have all consulted their Intel contacts and VERY late published FAKE NEWS articles letting Intel off the hook. But not every tech site takes large cheques from Intel...
If anyone here mentions 'SPECTRE', they are an Intel shill. Spectre is an 'exploit' that has no proven attack vector on AMD Ryzen parts, and the THEORETICAL vectors are simply patched on AMD with no performance hit. On Intel, Spectre CANNOT be patched, however. Either way, spectre is another TRIVIAL and insignificant bug- of which many thousands have already been dealt with on both AMD and Intel.
It is MELTDOWN that is the only issue that matters. Meltdown describes the NSA backdoor built into every Intel CPU designed to allow user code ring-0 access. This is an ARCHITECTURAL design of intel's CPU's, and cannot be fixed except by flushing and state resetting before EVERY virtual memory/IO operation- a massive slowdown of key functionality.
AMD's memory architecture is completely different, and does NOT allow this NSA requested attcak vector- not now, not ever.
Linux has gone crazy cos the exploit is a clear NSA backdoor, which Linux types will not accept. Microsoft, as an OS, is riddled with NSA exploits by Microsoft, so doesn't need a CPU hardware vector. Thus MS can happily patch the hole (on Intel only) at the cost of significant performance degradation on all mutli-core mulit-app use cases (which excludes most current games).
Intel cannot have a 'fixed' CPU til the end of 2019 at the earliest. Roadmapped Intel parts (like icelake) all have this NSA backdoor.
There is ZERO AMD issue- indeed AMD Ryzen is the future, just as the original AMD64 was the future when intel paid sites like this one to shill for the broken hopeless netburst design.
Re:Paid Intel shills will mention 'spectre'... (Score:5, Informative)
Original CERT notification:
https://webcache.googleusercon... [googleusercontent.com]
Replaced CERT notification:
https://www.kb.cert.org/vuls/i... [cert.org]
Re:Will this finally get rid of XP? (Score:5, Insightful)
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.
Re:I'm confused by this. (Score:4, Informative)
They’re changing the microcode to provide a mechanism for the OS kernel to implement the fix. They work together.
Re: (Score:3)
Re: (Score:2)
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
Re: (Score:2)
It would slow down code, may be by as much as 30%.
Re: (Score:2)
Re:True Scope Of Problem (Score:4, Informative)
Re: (Score:2)
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'.
Re: (Score:2)
Well... about about an attack in JS to read your lastpass vault? Seems significant enough to the average user to be concerned.
Re: (Score:3)
Re: (Score:2)
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?
Re: (Score:3)
It's not yours!
Re: (Score:3)
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 [newegg.com], designed for workstations and server racks.
It can use an embedded KVM [asus.com] for remote management, which is an IPMI 2.0 compliant interface.
So... go vote with your wallet or something.