That's about ME, not the recent Spectre and Meltdown that the article talks about: "Security researchers at the start of January publicized two flaws, dubbed Spectre and Meltdown"
> That's about ME, not the recent Spectre and Meltdown
I'm a layman, but spectre and meltdown seems like it can be a vehicle to exploit the intel management engine.
Once your on ME with a "designed"/obfuscated or hacked path. It is basically over, because ME a unix system; with lan access; can run java-applets while the host machine is powered down.
I hope it is only time before intel gives us the keys to our own ME jail. Hopefully ME will feature in some of these lawsuits.
> I'm a layman, but spectre and meltdown seems like it can be a vehicle to exploit the intel management engine.
No, or extremely unlikely at the very least.
Spectre and Meltdown allow a low privilege program to read (not write, only read) normally protected system memory accessed by higher privileged software through a shared cache. In the initial attack the privileged and attacking software run on the same CPU, but there are now "Prime" versions where attacker and privileged software can run on separate CPUs as long as they're on the same coherence domain (very simplified: they share some level of cache, at least the last level).
The ME on the other hand is a completely separate CPU. Although it can access system memory, likely in a coherent way, as I understand it has its own dedicated internal memories (sometimes called TCM for "tightly coupled memory" or CCM for "closely coupled meory", it's all the same: internal SRAM directly attached to a CPU core and dedicated to it). All the security context would be in these ME TCMs, so physically unaccessible from software running on the main CPU cores. It's a simple and efficient way to enforce security: true physical isolation with no sharing.
So Spectre and Meltdonw may enable a low privilege application to spy on communications between privileged software on the main CPUs and the ME, but it shouldn't help attack the ME itself. Unless the Intel ME devs did something horribly wrong, like storing sensitive ME data in the main system memory. Which would be very surprising really: if you put an isolated CPU for a ME, it's really to isolate the security state.
Since there are exactly zero [0] implementations of the JVM for Minix, your worries about Java applets running on ME while a machine is powered down can be put to rest. And 'powered down' activities of ME are very limited, and only applicable to certain ACPI states - not a magical way of using the computer when the PSU is switched off.
0. EDIT: Well, maybe not, see http://jainja.thenesis.org/ for instance. But still, I don't believe the NSA tailored access teams are building Java applets for their persistent malware...
> dubbed Spectre and Meltdown, that affected nearly every modern computing device containing chips from Intel, Advanced Micro Devices Inc and ARM Holdings.
My comment is regarding Meltdown which affects Intel CPUs almost exclusively. The wording used takes the same strategy as Intels own PR statement by blurring the line between Meltdown and Spectre in an attempt to play down how Intel specific the Meltdown vulnerability is.
Yes... like I said almost exclusively affects Intel CPUs. Just because 0.001% of non-Intel CPUs are affected while 100% of intel CPUs are, doesn't make Intel's strategy forgivable. I'm tired of seeing it echoed everywhere.
Tired of seeing what? The truth? The truth is that all these chips are affected.. it's one thing to ask for clarification on the numbers but this is not "fake news".
No. You really don't need that information to infer roughly what proportion are affected.
There is very little information out there about specifically which ARM chips are vulnerable, but it's always "High performance ARM designs". This is one of the few references:
> Intel is the company most significantly affected by these problems. Spectre hits everyone, but Meltdown only hits Intel and ARM. Moreover, it only hits the highest performance ARM designs. For Intel, virtually every chip made for the last five, ten, and possibly even 20 years is vulnerable to Meltdown.
Do you really think Apple has been using such a processor going all the way back to the first iPhone and iPad? Not to mention there are far more android phones and tablets than there are Apple ones (revenue !== number of devices) "High performance ARM designs" weren't really a thing until more recently, and they aren't going to be anywhere near a majority used in these devices... Remember what you are comparing this to.
The statement I'm complaining about is already factually wrong by assigning the Meltdown vulnerability to AMD, and then additionally it's extremely missleading by implying equality in it's application to ARM and Intel which is anything but. I'm honestly surprised how many of you replied to my comment in disagreement, I suppose it just shows how well PR FUD works and spreads if it's not dispelled loudly enough. Still I expected more on HN.
Well the article does start out "Intel Corp said on Friday..." which kind of clues you in that it was written [I won't outright say "from" as in "cribbed from" but let's say somewhat charitably, "after reading"] a press release from Intel themselves.
I agree with you that the wording, while basically accurate, does sound an awful lot like Intel talking, and if that first line weren't there, it would seem a bit suspicious like maybe the suit is back again - http://paulgraham.com/submarine.html
That would simply promote intentional ignorance. Even then Meltdown is part of a known class of attacks namely race conditions, Intel simply messed up.
Well, actually, the cache sidechannel timing attacks were fairly well known for quite a while.
It's just nobody put two and two together.
This is actually mostly due to lack of public information in the processor manuals.
Otherwise it's quite likely it would have been discovered 5-6 years ago at least.
The fact that modern processors speculatively load memory has been known for a long time (and it's not like the fact that permission checking only occurs during retirement is documented...the reason no one considered it a problem was that it was thought of as an implementation detail and literally something you wouldn't document because in the future you might arbitrarily change it). This isn't exactly novel information...and putting two and two together only seemed obvious after the fact.
Well you know, I always thought accurate rollback was one of the hardest things about speculative execution. But just like other hazards, OF COURSE the CPU vendors have a deep understanding of them and a bag of tricks I have never heard of to avoid them. I am still incredulous about that screwup. It is such an obvious problem.
Hey, maybe memory traffic sidebands for speculative execution are next. You can undo cache data changes, you cannot undo the slowing down of simultaneous other memory traffic. And who knows, maybe everyone was like "we cannot prevent all measurable side effects, so screw it #YOLO". And nobody can admit that due to liability issues. That seems quite likely to me because it doesn't involve hundreds of very smart experts missing an obvious problem.
You don't have to rollback for meltdown. The read can be masked to zero. There is already logic to do things like cancel page walks, so this isn't a very big fix.
I think specter should be fixed in software with some assistance from hardware, but overall with ooo, a process shouldn't expect privacy against itself.
AFAIU the Spectre software "fixes" are either extremely expensive, or still exploitable, or both. I think you're correct about OOO, and there goes the security of all current HTML/JS engines.
> Spectre software "fixes" are either extremely expensive
They don't have to be done everywhere though. Just on js array accesses and the masking options seem better than the fencing option. It doesn't have to be done on every array access, and i many cases it probably isn't practically exploitable. We still don't have a working, real world exploit in js without assistance.
The speculation windows are in practice pretty small (10 instructions maybe), plus you have to find the memory you want to read, mistrain the branch predictor and flush the cpu cache between every read, etc... And do all this before that piece of memory you found moves or is overwritten.
> there goes the security of all current HTML/JS engines.
Pretty much. In places devs forget to protect against spectre there can be a possible exploit. Ooo causes similarly difficult to find issues with threading where the dev needs to think long and hard about how instructions hit the cpu, but we manage.
I love how all of a sudden the problem is obvious - so obvious it's existed for a decade with no known exploit, while speeding up processors considerably.
Intel should have hired all these really smart people on Reddit and HN. Imagine how much safer and faster our processors would be!
It's a screw up in the most complicated devices humanity has ever designed. It's borderline magic that they even exist, let alone the political stability required for 50 years of constant gains in processing power per dollar.
But nevermind that, they're a bunch of "LOL #YOLO" about security types, we should sue them because your data center power went up and now our dumbass 'world changing app' to look at random kittens as a subscription service is no longer profitable!
I think humanity doesn't deserve scientists and engineers.
Like DannyBee said, side-channel attacks were well known and security researchers had warned against them since at lest 1995. In fact both MacOS's kernel and the Linux kernel had some basic protections from side-channel attacks for years now, which unfortunately don't work if an attacker can dump the entire contents of all physical RAM.
Intel has has a long time to mitigate the issue. They didn't because it made their processors faster, and they chose profits over security.
Literally since 1995. There's no way Intel hasn't read this report from the NSA detailing how insecure the x86 platform is where they literally call out this exact feature as a security risk. This feature that was not accidental, but intentionally designed.
Why exactly are you blindly defending Intel, especially with such easily disprovable arguments?
It isn't the cache side channel that is the important part of meltdown. Flush-reload is just out the information is retrived and ask acceptable problem.
The problem is data hitting the cache when it comes from an unreadable page. Meltdown looks like a bug in the cache hit logic because the page information is already in the tlb, and the fix is probably fairly trivial.
If the unreadabld page doesnt hit cache or is never mapped there in the first place, spectre can only read its own process.
Well buckle your seatbelt, because 32 plaintiffs and counting will be using discovery and god knows what else to prove just that. Intel had better be utterly innocent, or have excellent coverup skills.
No. Security is already a non-concern amongst non-technical people, who unfortunately control most leadership positions. Protection from liability only means we get to see more, and worse, BS like this in the future.
We need to hold companies even more accountable than what they already are. 32 lawsuits is not enough, more like 320!
Assume you build a product using TLS as the underlying encryption layer. Unfortunately, few months later, some bored mathematician figures out how to completely break AES and ECDH.
Should you be held accountable for choosing "weak" ciphers?
> Should you be held accountable for choosing "weak" ciphers?
That would be up to the jury. For something like your scenario, as long as you're keeping up and using industry best practices, you almost certainly would have nothing to worry about. In fact, a case like that would likely be dismissed immediately by the judge before it ever went to trial.
Okay then, let's assume you are doing something more cutting edge. Like speculative execution involving memory prefetching.
What are "industry best practices" for that? There are like 3 companies which do this competitively at scale and each of them guard their methods like it's the Coca-Cola recipe.
Sympathetic to the notion given how difficult/useful it is to design a chip. But someone has to bear the cost of this. Chip designers are the party most capable of mitigating the harm. Seems reasonable to ask them to pay. See e.g., https://en.wikipedia.org/wiki/Coase_theorem
There's no externality to speak off here, so Coase doesn't apply. The costs, even if unexpected, are borne by the people who buy the chips, not random bystanders.
Yes. Bugs are called bugs because you could actually find bugs among triodes and they could cause the computer to malfunction. Then the wording was extended to software bugs.
Spectre can be avoided (at small performance cost on new CPUs) with microcode updates and OS fixes. Meltdown can be fixed just at the OS level.
At this point, whether you're releasing a chip with or without the vulnerability is not an issue. Fixing them will make you look better in benchmarks if anything, because you don't need anymore the slow PTI mitigation.
Am I the only one who thinks that now would be a good time to buy intel shares, or even wait a bit more until these suits are won (intel will likely lose), so the stock price will go down even further. There is no way intel will lose its market position, so stock prices are likely to go back up after all this drama settles down...
>There is no way intel will lose its market position
Famous last words if I ever heard them. Ryzen and threadripper are a significant threat especially knowing that AMD is not vulnerable to meltdown (only Spectre).
But the large margins are in Xeons for enterprise and HPC computing. We use high-end Xeon machines for research and would think twice before purchasing AMD. Besides a generally good reputation and good performance, Intel has a great ecosystem with Intel MKL, ICC, etc.
Besides that, Spectre also affects AMD and many ARM CPUs.
> We use high-end Xeon machines for research and would think twice before purchasing AMD
Ryzen supposedly have a price-performance benefit over Xeons for multi-threaded workloads.
What would you say the main reasons for staying with Xeons are for your type of research? Is single threaded performance intrinsic to the type of computation your research requires? or do those optimised math libraries you mentioned bring so much practical benefit as to outweight any current raw price-performance differences?
Soz, lots of questions, was just interested in how it applies to HPC based research in reality.
At least my case, our compute servers are 4 dual Xeon servers in a 2U format, sold by Dell. I haven’t yet found any vendor with the same core density based on AMD.
The Dell EMC PowerEdge R7425 is a dual Epyc server in 2U format, sold by Dell. The top end Epyc chip gets you 64 cores (128 threads). The core density is competitive, along with its supported IO device (eg: NVMe drive) density.
Supermicro blows AMD out of the water when it comes to density.
Here's equivalent 4 node in 2U AMD systems (they differ based on disk configuration -- SAS, NVME, or a mix of both). They also support Supermicro SIOM, so you can choose what integrated networking you want:
That being said, these don't make a lot of sense unless you're very space-constrained, or your racks have a ton of power available. Given a 30A 208V circuit, I could only safely run three of the above AMD systems at full power. I'd rather just get dedicated 1U or 2U servers, and not have to make compromises about expandability or serviceability.
What would you say the main reasons for staying with Xeons are for your type of research?
We use Intel MKL in some applications. We just use the BLAS interface, but Intel MKL is generally the fastest BLAS implementation. Obviously, it is optimized for Intel CPUs.
Also, with many vendors it is easier to get >= 768GB RAM 64 core machines using Intel Xeon CPUs.
If the behaviors (bus timing logic and such) that are being used to spill information across process and privilege boundaries actually were fully documented, wouldn’t the liability fall on the people who used these chips to write multi-user environments without knowing or understanding the implications of the technical details?
It's very well documented that writing outside array boundaries in C can cause undefined behavior (leading to arbitrary code execution no less!), yet Adobe isn't exactly sued for every buffer overflow in Flash.
88 comments
[ 3.0 ms ] story [ 168 ms ] threadhttps://en.wikipedia.org/wiki/Intel_Management_Engine
I'm a layman, but spectre and meltdown seems like it can be a vehicle to exploit the intel management engine.
Once your on ME with a "designed"/obfuscated or hacked path. It is basically over, because ME a unix system; with lan access; can run java-applets while the host machine is powered down.
I hope it is only time before intel gives us the keys to our own ME jail. Hopefully ME will feature in some of these lawsuits.
No, or extremely unlikely at the very least.
Spectre and Meltdown allow a low privilege program to read (not write, only read) normally protected system memory accessed by higher privileged software through a shared cache. In the initial attack the privileged and attacking software run on the same CPU, but there are now "Prime" versions where attacker and privileged software can run on separate CPUs as long as they're on the same coherence domain (very simplified: they share some level of cache, at least the last level).
The ME on the other hand is a completely separate CPU. Although it can access system memory, likely in a coherent way, as I understand it has its own dedicated internal memories (sometimes called TCM for "tightly coupled memory" or CCM for "closely coupled meory", it's all the same: internal SRAM directly attached to a CPU core and dedicated to it). All the security context would be in these ME TCMs, so physically unaccessible from software running on the main CPU cores. It's a simple and efficient way to enforce security: true physical isolation with no sharing.
So Spectre and Meltdonw may enable a low privilege application to spy on communications between privileged software on the main CPUs and the ME, but it shouldn't help attack the ME itself. Unless the Intel ME devs did something horribly wrong, like storing sensitive ME data in the main system memory. Which would be very surprising really: if you put an isolated CPU for a ME, it's really to isolate the security state.
0. EDIT: Well, maybe not, see http://jainja.thenesis.org/ for instance. But still, I don't believe the NSA tailored access teams are building Java applets for their persistent malware...
WTF, spreading FUD on Intels behalf again?
AMD's press release on their susceptibility to Spectre: https://www.amd.com/en/corporate/speculative-execution
Do you know what proportion of the number of x86 CPUs that Intel has made over the last decade that are affected?
There is very little information out there about specifically which ARM chips are vulnerable, but it's always "High performance ARM designs". This is one of the few references:
> Intel is the company most significantly affected by these problems. Spectre hits everyone, but Meltdown only hits Intel and ARM. Moreover, it only hits the highest performance ARM designs. For Intel, virtually every chip made for the last five, ten, and possibly even 20 years is vulnerable to Meltdown.
https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre...
Do you really think Apple has been using such a processor going all the way back to the first iPhone and iPad? Not to mention there are far more android phones and tablets than there are Apple ones (revenue !== number of devices) "High performance ARM designs" weren't really a thing until more recently, and they aren't going to be anywhere near a majority used in these devices... Remember what you are comparing this to.
The statement I'm complaining about is already factually wrong by assigning the Meltdown vulnerability to AMD, and then additionally it's extremely missleading by implying equality in it's application to ARM and Intel which is anything but. I'm honestly surprised how many of you replied to my comment in disagreement, I suppose it just shows how well PR FUD works and spreads if it's not dispelled loudly enough. Still I expected more on HN.
I agree with you that the wording, while basically accurate, does sound an awful lot like Intel talking, and if that first line weren't there, it would seem a bit suspicious like maybe the suit is back again - http://paulgraham.com/submarine.html
It's just nobody put two and two together. This is actually mostly due to lack of public information in the processor manuals. Otherwise it's quite likely it would have been discovered 5-6 years ago at least.
Hey, maybe memory traffic sidebands for speculative execution are next. You can undo cache data changes, you cannot undo the slowing down of simultaneous other memory traffic. And who knows, maybe everyone was like "we cannot prevent all measurable side effects, so screw it #YOLO". And nobody can admit that due to liability issues. That seems quite likely to me because it doesn't involve hundreds of very smart experts missing an obvious problem.
I think specter should be fixed in software with some assistance from hardware, but overall with ooo, a process shouldn't expect privacy against itself.
They don't have to be done everywhere though. Just on js array accesses and the masking options seem better than the fencing option. It doesn't have to be done on every array access, and i many cases it probably isn't practically exploitable. We still don't have a working, real world exploit in js without assistance.
The speculation windows are in practice pretty small (10 instructions maybe), plus you have to find the memory you want to read, mistrain the branch predictor and flush the cpu cache between every read, etc... And do all this before that piece of memory you found moves or is overwritten.
> there goes the security of all current HTML/JS engines.
Pretty much. In places devs forget to protect against spectre there can be a possible exploit. Ooo causes similarly difficult to find issues with threading where the dev needs to think long and hard about how instructions hit the cpu, but we manage.
Intel should have hired all these really smart people on Reddit and HN. Imagine how much safer and faster our processors would be!
It's a screw up in the most complicated devices humanity has ever designed. It's borderline magic that they even exist, let alone the political stability required for 50 years of constant gains in processing power per dollar.
But nevermind that, they're a bunch of "LOL #YOLO" about security types, we should sue them because your data center power went up and now our dumbass 'world changing app' to look at random kittens as a subscription service is no longer profitable!
I think humanity doesn't deserve scientists and engineers.
Security is absolutely neglected all over the place in IT, including in things I've worked on myself. It's too expensive.
Intel has has a long time to mitigate the issue. They didn't because it made their processors faster, and they chose profits over security.
Literally since 1995. There's no way Intel hasn't read this report from the NSA detailing how insecure the x86 platform is where they literally call out this exact feature as a security risk. This feature that was not accidental, but intentionally designed.
Why exactly are you blindly defending Intel, especially with such easily disprovable arguments?
The problem is data hitting the cache when it comes from an unreadable page. Meltdown looks like a bug in the cache hit logic because the page information is already in the tlb, and the fix is probably fairly trivial.
If the unreadabld page doesnt hit cache or is never mapped there in the first place, spectre can only read its own process.
We need to hold companies even more accountable than what they already are. 32 lawsuits is not enough, more like 320!
Should you be held accountable for choosing "weak" ciphers?
That would be up to the jury. For something like your scenario, as long as you're keeping up and using industry best practices, you almost certainly would have nothing to worry about. In fact, a case like that would likely be dismissed immediately by the judge before it ever went to trial.
What are "industry best practices" for that? There are like 3 companies which do this competitively at scale and each of them guard their methods like it's the Coca-Cola recipe.
https://thenextweb.com/shareables/2013/09/18/the-very-first-...
http://www.jamesshuggins.com/h/tek1/first_computer_bug.htm
Obligatory working scihub link: https://sci-hub.la/10.2307/455415
tl;dr - Error-prone semi-automatic telegraph keyers were called bugs.
At this point, whether you're releasing a chip with or without the vulnerability is not an issue. Fixing them will make you look better in benchmarks if anything, because you don't need anymore the slow PTI mitigation.
Famous last words if I ever heard them. Ryzen and threadripper are a significant threat especially knowing that AMD is not vulnerable to meltdown (only Spectre).
First time I've EVER bought an AMD product, and I'm definitely impressed.
Besides that, Spectre also affects AMD and many ARM CPUs.
Ryzen supposedly have a price-performance benefit over Xeons for multi-threaded workloads.
What would you say the main reasons for staying with Xeons are for your type of research? Is single threaded performance intrinsic to the type of computation your research requires? or do those optimised math libraries you mentioned bring so much practical benefit as to outweight any current raw price-performance differences?
Soz, lots of questions, was just interested in how it applies to HPC based research in reality.
https://www.servethehome.com/dual-amd-epyc-7601-processor-pe...
Here's equivalent 4 node in 2U AMD systems (they differ based on disk configuration -- SAS, NVME, or a mix of both). They also support Supermicro SIOM, so you can choose what integrated networking you want:
http://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-HNC...
http://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-HNR...
http://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-HTR...
If you wanted even more density, there's the MicroCloud and MicroBlade series (although they use Intel processors):
https://www.supermicro.com/products/MicroBlade/
https://www.supermicro.com/products/nfo/MicroCloud.cfm
That being said, these don't make a lot of sense unless you're very space-constrained, or your racks have a ton of power available. Given a 30A 208V circuit, I could only safely run three of the above AMD systems at full power. I'd rather just get dedicated 1U or 2U servers, and not have to make compromises about expandability or serviceability.
We use Intel MKL in some applications. We just use the BLAS interface, but Intel MKL is generally the fastest BLAS implementation. Obviously, it is optimized for Intel CPUs.
Also, with many vendors it is easier to get >= 768GB RAM 64 core machines using Intel Xeon CPUs.
1: https://github.com/libmir/mir-glas
2: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...