New flaw in Intel chips lets attackers slip their own data into secure enclave
techcrunch.com
techcrunch.com
It has a good explanation, videos and FAQ.
(the Techcrunch post is just horrible)
When I click on a Techrunch link, it tries to redirect me to some tracking url on advertising.com. That would probably collect data about me, set cookies and send me back to Techcrunch. Since I do not allow that, I cannot read Techcrunch articles at all.
Lets see what others think. I made an Ask HN from this:
What matters in actual journalism, and what we should encourage, elevate, and credit, is the BEST reporting. That is, the most accurate, most readable, most informative, most honest.
Factors like misleading clickbait, content-free speculation, inflammatory commentary, and poor fact-checking need to disqualify outlets from consideration when determining which news source to promote on a given story.
I don't mean necessarily junking a publisher categorically for past sins, but rather looking at each story individually and determining whether someone else is reporting it BETTER.
Fools rush in.
Linking to a paywalled source for an audience that you can't guarantee are all subscribers is like telling everyone to just trust you that a story exists.
I believe it would be tremendously helpful when discussion threads float up comments that help people understand the problem better and what, if anything, they can do (including waiting for patches or taking other precautions).
The basic idea is to be able to run code on an Intel processor that cannot be tampered with or even examined by any other part of the system, including the OS, hypervisors, etc. The entire code and data segment of this program runs in its own world, the “secure enclave”, in user mode (ring 3). The attack model is that every piece of software executing on the CPU (user code, OS code, hypervisors) and every bit of hardware outside the CPU (network interfaces, hardware buses, memory interfaces) could be compromised and attempting to leak data from your Secure Enclave, and the enclave code/data should still remain tamper proof and unreadable. The SGX implementation even includes an attestation system, using a trusted server operated by Intel, which will attempt to verify that the CPU itself is not compromised.
The entire thing depends on a lot of cryptography. Sealing keys to encrypt data that will be persisted to disk from the enclave. Memory protection keys to encrypt everything going to RAM. Page encryption keys to encrypt any memory that the OS tries to page out. Attestation keys to cryptographically verify that the CPU measured itself to be OK. Cryptographic signatures to validate the initial enclave code and data to protect against tampering of the initial state. Session keys to protect the enclave’s communication with whatever application server is providing the code/data for the enclave’s computation. The OS and even the ring 3 application hosting the enclave have a MITM position on absolutely everything the enclave does, so the disclosure of just one of these keys breaks the security of the whole system.
I am not surprised at all that SGX wound up being vulnerable to a low-level CPU attack. The attack surface is way too big and there are too many points of failure.
Most secure systems assume that the CPU is functioning correctly. It is not clear that you can do anything securely if the CPU is buggy.
The SGX design was created on top of the instruction specification, not on top of specific buggy processors. Hence the vulnerability! The threat model for SGX did not consider incorrect processor implementation.
Note that the access checks are only bypassed when executing speculatively, because they get reordered to occur before the checks take place. It's not that the checks aren't there; it's that they're too late and this allows for tainting micro-architectural buffers with the side effects of the invalid loads.
https://www.usenix.org/system/files/conference/usenixsecurit...
First impression, but is it a ridiculous notion to assume that loading code into the secure area wouldn’t be used by malware? Like if you were trying to avoid detection for the rest of the system that doesn’t seem like a great place to do it?
The Intel deep dive [0] is a pretty solid addition to the original paper [1].
It looks like Ice Lake processors are going to be the first ones that are not affected [2]. Based on the deep dive, it sounds like these still aren't perfect (they don't completely avoid forwarding values to dependent instructions from faulting loads). They instead exhibit some behavior they call "zero-at-ret", which Intel says is not expoitable in practice.
Intel does not explicitly say Ice Lake is zero-at-ret, but reading between the lines this seems to be the case ("parts generally exhibiting Zero-at-ret behavior... will be documented as 'not affected'.") Only Ice Lake is listed as not affected, so they likely would not put this caveat in there if this did not apply to Ice Lake.
[0] https://software.intel.com/security-software-guidance/insigh... [1] https://lviattack.eu/lvi.pdf [2] https://software.intel.com/security-software-guidance/insigh...
1) You can disable kPTI without opening the door to Meltdown (which let you directly read kernel memory as usermode).
2) You can re-enable hyperthreading while allowing virtualization (VMs) without obvious issues (l1tf used to allow users to read kernel memory through VMs). I don't know which, if any, distros do this, but it's the prudent thing to do if you care deeply about security. (Linux may have the scheduling fixes by now that also fix this, but I honestly haven't followed them, and they didn't have them in like November when I last checked.)
Others:
1) I'm honestly unsure if you can recompile kernels without "retpoline", but it's not a super big perf impact anyway, at least not compared to those two mitigations.
2) I'm not super familiar with the "MDS" vulnerabilities, so I don't know how bad the perf impact of their mitigations are, or how bad their impact is.
3) There's some TSX issues, which I'm also unfamiliar with, also probably don't matter much perf wise.
If you are paranoid, or have a multi-tenant machine, I'd still leave these on (and I'd particularly leave hyper-threading off, even on AMD), since we haven't stopped seeing new side channels. Hyper-threading is basically asking for problems on multi-tenant machines.
Honestly, if your machine is not multi-tenant, and you can tolerate some risk (e.g. you don't care if anyone sitting at your machine can read all of RAM, including potential malware), I'd just disable all this stuff. Unless you've run into particular hiccups (you compile linux kernels all day and you need the extra cores), I wouldn't do it.
- Maybe I should buy an Intel system again because of the performance counters and other nice things.
Another Intel attack surfaces
- Yep, I shall go AMD this time...
From 2 days ago, in case you weren't aware.
itself it's not a problem but if you pair it with something else it destroys a major line of defense against that something else.
AMD is still architecturally vulnerable to some variants of SPECTRE, they just consider it "hard to exploit", but they do recommend you run KASLR to harden against it. Well, so much for that.
It works pretty well against remote code execution because it's hard for an attacker who can't already execute arbitrary code on your machine to determine the address space layout. In principle it can also be used to protect the kernel against user processes, but that's much harder because a process that can already execute arbitrary user code on the same machine can use a variety of side channel attacks like this to determine the kernel address space layout.
KPTI was originally proposed to close some of those side channels, but it's kind of expensive. It only got enabled by default (on Intel) because it also mitigates Meltdown, which is a much worse problem. It also doesn't handle all of the side channels:
http://www.cs.ucr.edu/~nael/pubs/micro16.pdf
Meanwhile, if some kernel code is vulnerable to Spectre (i.e. the Spectre mitigations are not implemented properly), it could allow the attacker to read arbitrary kernel memory. That is obviously very bad, but the ability to read arbitrary kernel memory implies that the attacker can already determine the kernel address space layout, so I'm not sure how KASLR would be helpful in mitigating that.
No, it's a misunderstanding to say that the flaw in the "Take A Way" whitepaper depends on a mechanism already patched. Attack scenarios which are used in the paper to show the feasibility of the 2 new side channels are patched (except the KASLR entropy reduction), but the side-channels themselves are not patched.
And might never be patched just like FLUSH+RELOAD never was. And the paper itself even points out that FLUSH+RELOAD is a more applicable attack than Load+Reload is:
> Comparison with Flush+Reload. While Flush+Reload invalidates a cache line from the entire cache hierarchy, Load+Reload only evicts the data for the sibling thread from the L1D. Thus, Load+Reload is limited to cross-thread scenarios, while Flush+Reload is applicable to cross-core scenarios too.
Collide+Probe is more interesting as it can use virtual address instead of physical address in comparison to Prime+Probe. That may get a microcode update to do a way flush on context switch as part of general Spectre mitigations (just like the branch predictors are), but it can also be handled entirely in software by adjusting how the AES implementation works as the paper also talks about.
But fundamentally what these attacks enable are super old & well known, with multiple existing mechanisms that fulfill similar roles. It's why Spectre/Meltdown never focused on the side-channel part of the attack, because it seems to just be assumed side-channels will always exist. And why the paper used existing, documented vulnerabilities to do the exploit side of their PoC, just changing the side-channel used to ex-filtrate the data.
Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it?
It still has to be published. The article doesn't claim to break all the isolation mechanisms of the processor like Spectre/Meltdown. Why should we compare this paper with Spectre/Meltdown?
> Is there something particularly unique or severe about "Take A Way" other than techchrunch's bad reporting of it?
Yes, there are at least three things in "Take A Way" which is interesting:
- These side-channels are harder to detect because it doesn't require a very intensive use of the cache (no flush / filling all cache ways / etc.). A single collision is enough to evict a targeted cache line.
- It allows to set up a covert channel that can transfer up to 588.9 kB/s.
- They did a reverse engineering job on a processor mechanism and its undocumented hash function.
That was sort of my point, we shouldn't be making that comparison but further up in the comment chain that's exactly what was being done.
The paper itself is great and definitely should exist. But it's not a counter-argument to "yet another Intel attack surfaces" either.
It bothers me and I don’t really understand. There are some really vile comments about Intel and unreasonable praise for AMD - simply because it’s the “underdog”. What is this? Some kind of a sport that one is rooting for the “underdog”. It’s a multi billion dollar corporation.
I should clarify that my frustration isn’t about what the OP said. It’s a general observation.
What gave you that idea? This thread was clearly about someone building a local PC. There's no reason to assume that'd be a server chip?
But even in the server world go look up any comparison of Epyc Rome vs. Intel Xeon and you'll still struggle to find a reason to go Intel. The Epyc 7742 is in a league of its own at this point.
This entire post is about Intel security flaw where we just had one discovered for AMD yesterday! But people are not as vile about AMD but become hostile when it comes to Intel. Why? There are some toxic people defending both sides with passion. I’m baffled. If this isn’t “Fanboys”, what is?
Regarding comparisons, I’m yet to see a conclusive source that points at AMD > Intel for server workloads - benchmarking these things is complex. Power, efficiency, workload types, etc matter. So it’s not as simple as saying “Hey, AMD won”.
I’m disappointed at the hostility for pointing out fanboyism on HN. It’s present whether one denies it or not.
Edit: Holyshit. I won’t be responding anymore. This has become an unproductive discussion simply for pointing out the bias in supporting the “underdog”. I have no way to prove this but I stand by my observations and what my eyes see - given Apples and Apples comparison for metric X or security flaw X, people have a deep bias for supporting the “underdog”. I saw this first hand back in 2006 when Intel was the “underdog”. This is a fact and no amount of massaging on HN or the Internet forums will change that. I’m again disappointed in the HN community’s response.
I work as an HPC administrator and I just want to tell a single thing:
We were unable to buy first generation EPYC processors because almost all of the production run is bought by Google, Amazon and Dropbox. They weren't offered by many vendors as general availability servers because it wasn't possible.
It's a bit late here so, I cannot do much research but I'll leave this Phoronix article [0] about RocksDB performance.
Phoronix Test Suite sounds a bit cheesy but, as far as I can see, it's becoming a reputable benchmark suite. I was troubleshooting a server from a big manufacturer and, its official live CD has this thing installed to see how system performs.
Also our fellow HPC centers says that EPYC is not vaporware in terms of performance.
[0]: https://www.phoronix.com/scan.php?page=article&item=intel-am...
Because it very much comes across as though you've got an axe to grind. OP was "maybe sort of" going to build an AMD box, for which there are a lot of good reasons irrespective of the bug on topic, and this set him over the top.
His post doesn't really exude fanboy behavior, and your comment - while possibly appropriate for some other post - isn't really appropriate to OP.
AMD's was a new side channel that doesn't appear to be that different from existing side channels like flush+reload. Some pros (and cons) over the established ones, but you're not attacking anything with those either. It's how you ex-filtrate data after a successful attack.
This, by comparison, is a new attack vulnerability. They are different severity, and I'd expect here of all places to recognize & acknowledge that. I'm baffled as to why you seem to be expecting something different?
> Regarding comparisons, I’m yet to see a conclusive source that points at AMD > Intel for server workloads - benchmarking these things is complex. Power, efficiency, workload types, etc matter. So it’s not as simple as saying “Hey, AMD won”.
Did you look? Yes benchmarking these is complex, but when one CPU wins the overwhelming majority of every comparison on every metric it reeks of fanboyism to then claim it's "not conclusive." There's no shortage of server CPU benchmarks done in this space. If you have a specific comparison that's missing then say it. Otherwise you're just accusing people of the fanboy behavior that you're exhibiting.
But here: https://www.anandtech.com/show/14694/amd-rome-epyc-2nd-gen/1...
"For those with little time: at the high end with socketed x86 CPUs, AMD offers you up to 50 to 100% higher performance while offering a 40% lower price. Unless you go for the low end server CPUs, there is no contest: AMD offers much better performance for a much lower price than Intel, with more memory channels and over 2x the number of PCIe lanes. These are also PCIe 4.0 lanes. What if you want more than 2 TB of RAM in your dual socket server? The discount in favor of AMD just became 50%.
So has AMD done the unthinkable? Beaten Intel by such a large margin that there is no contest? For now, based on our preliminary testing, that is the case. The launch of AMD's second generation EPYC processors is nothing short of historic, beating the competition by a large margin in almost every metric: performance, performance per watt and performance per dollar."
Like every review of Rome is like this. AMD released an incredible product. Credit where credit is due is not fanboyism.
Referring to people as "fanboys" is one of them. There's a reason for this: it's an insult, for starters. Furthermore, it leads to unproductive discussions. More heat than light.
There's almost always a way to express yourself that doesn't involve being dismissive and insulting. You may not realize that's what you're doing by saying "fanboy". But it is what you're doing.
If you'd pulled a highfalutin' word like "partisanship" you would probably find a productive conversation. Just avoid fanboy, circlejerk, and other obvious flamebait, and you'll be fine.
The schadenfreude isn't coming from nowhere.
You can just flip the sides, if AMD controlled 85% market share, the shareholders would demand the same unless we have laws preventing anti-competitive behavior.
That said, I do acknowledge the business leadership at Intel and their toxic attempts to prevent competition.
Legislation has nothing to do with "underdog" or marketshare. It has to do with anti-competitive practices regardless of the party. The same laws would apply to Intel or AMD regardless of their market share.
and people who bought AMD stock, but none of Intel or anything much else, because they see the CPU market as a 0 sum game. AMD was a darling of first time investors on a certain platform and they don't diversify. It’s not that their constant wall of pro-AMD stock noise is going to affect the stock price, but it also becomes a bit of an emotional thing for them.
All the AMD posts here end up looking a lot more like Reddit than Hacker News
HN is not exactly the source of truth for anything technical, but generally people are either in the ballpark on technical comments, or (more likely) get corrected by someone who is.
On AMD posts that doesn’t happen and it just becomes a low quality cesspool of “I just bought a gaming PC and chose AMD”, “Intel is on life support right now omg”, and a few poorly supported rationalizations of the post's topic.
And when you call it out these people assume you’re defending Intel (because to them it’s a holy war)
I consider AMD for its new Infinity Fabric and multi-core performance. I also use performance counters a lot to optimize my code and improve my understanding of modern processors even further.
This will be my 5th build and I've built 2 AMD and 3 Intel systems for long-term use in a span of ~20 years. I think it's logical to go for a high-performance system with lower attack count/surface to reduce the chance of getting performance-crippling uCode or Kernel patches in the future.
I was probably a fanboy while overclocking my 1433MHz 1700+ to 2.2GHz with ABIT ultra mother boards. These days and mindset has long gone, at least for me.
OTOH, I have more than enough cutting edge hardware from major vendors to manage and play with. So, I'm not hungry for anything really.
I also did root for AMD when I was younger however, in a more down-to-earth fashion. AMD was providing 90% of the performance of a comparable Intel system and, Intel was so dominating that AMD was at the brink of collapse.
I rooted for AMD because I wanted them to survive. I wanted competition. I wanted to see more interesting ideas from more vendors. I also reacted to that infamous "AMD's thermal management doesn't work" video from Tom's Hardware because my and my friends' AMD systems' thermal management features were working fine.
I rooted for AMD because they were more dynamic when compared to Intel. They allowed overclocking, experimenting. They had more chipset choices and some of these chipsets did interesting things that Intel was not daring to try.
Intel was a company wearing suits even in weekends, while AMD was going to work putting on jeans and, it was exciting for young enthusiasts.
AMD still has this in its gene though. They were kind and open enough to revise their GPU silicon to enable truly open source drivers sans HDCP. Their company culture is different and I root for the underdogs sometimes because, I root for competition.
Except there is. Hence why Skylake suffered from Meltdown while AMD didn't. Skylake's design is to do ACL checks at instruction retirement instead of up front. AMD's is the reverse.
Software workarounds for Meltdown exist, yes, but the Skylake architecture still fundamentally has that insecure design.
These secure enclaves are routinely used for extremely sensitive data, surely it's more worth stealing than someone's WiFi credentials.
Edit: So yeah, I'm not sure it's worth all of the complexity of an SGX attack. There are probably easier ways to get the credit cards.
An attacker doesn't want to remotely steal your iPhone or laptop. At most they want to unlock it after they steal the physical device.
Injecting a bios worm into a data center is more of a concern.
I've never used a web store checkout system that wasn't based on browser forms, or any mechanism that felt like asking a secure enclave to sign a transaction. Google Chrome offers to store your credit card numbers for you, but that's just so it can autofill web forms.
Apple Pay or whatever, sure, on their hardware. Macbooks, I'd think it uses the touchbar secure enclave. But nothing really uses SGX on Intel except Netflix DRM.
E.g. you might want your credit card processing in an enclave even if it's your own card, simply to hide it from any rootkits or malware you may have installed.
On the other hand, interest in this topic among the public has definitely grown since branding departments started getting their hands on the exploits and Bloomberg published that sensationalist Micro story so it's a self reinforcing cycle.
Considering it was published with the intent to "move markets" I would consider it a fraudulent Micro story.
That’s not to say systems were all insecure in the past. You just didn’t trust computers to be secure.
Compare and contrast their handling of the stream of vulnerabilities in the past few years to the FDIV bug in the 90's. The FDIV bug was the first time I remember a hardware bug making national news. Intel just about shit themselves over this apologizing profusely, offering free processor swaps, billion dollar write down, talking about how this would never happen again etc. A big part of the reason they took it so seriously was that there were still a number of other alternative CPU manufacturers trying to compete with Intel at the time and it was far from certain that x86 would become the undisputed ISA for PCs. (this was pre-Windows 95) All this, and the vast majority of people would never ever experience the FDIV bug even if their processor had it.
Times change, but the lesson remains the same: competition is good.
Since this vulnerability class was previously unknown, hardware didn't have much protection against it, except by accident (or as a side effect of more conservative design). Being in hardware, they are difficult or impossible to workaround in software. And they were found in common hardware most people have. This all lead to them being widely reported by the tech press.
Spectre was more impressive than a new idea: it was a brilliant execution of an idea that every architect eventually had. Rowhammer was similar. Everyone knew that it was possible to get boned by physics, but it can happen at an arbitrary place in an arbitrary way that isn't captured by any model. Rowhammer wasn't impressive because it was an idea, but because it was a simple, obvious in retrospect, way to exploit physics to bypass the models.
I remember reading papers in the mid to later 90s on just this topic, in regard to processing on top secret systems.
Most of the infeasiblility at the time was of running code on remote systems at the same time. Things like javascript were not everywhere at the time and most computers only had one core.
Several years ago it felt like we barely went a week between Flash vulnerabilities.
Then someone found a major vulnerability in the JVM, and that became the centre of attention, and it felt like we were having to patch the JVM every single month.
Then something else came along and all eyes got focussed on that... rinse, repeat.
Right now the CPU is becoming a focus. We've probably got another couple of years of this before it'll settle down.
CPU is interesting because it's a lot harder to exploit, it's much less by way of finding low hanging fruit, unlike Flash and JVM.
And now that code can adversarial effect you?
That's why it became such a hot topic.
CPU designers have made complex architectural decisions to speed up execution. In the case of spectre, it's to speed up single-threaded execution. In the case of this, it's to optimize security features. An analogous case is AES256, which was chosen because it's fast. But it's fast because the s-boxes use the private key as an index into an array, so there's caching. But this introduces a side-channel, because based on time to execute you can infer the private key.
Although it is unlikely, I remain wishful that this continued barrage of side-channel attacks will usher in the return of the era where people actually own their hardware 100%, rely on processor protections as defense against mistakes and not malice --- as was the original intent of 286 protected mode --- and understand that attempting to isolate trusted and untrusted code on the same hardware is ultimately futile.
Clouds will probably stick with traditional server blades until transient attacks are found which simply can't be defeated, even with new silicon. Even replacing entire DCs worth of blades would be cheaper than reworking the fundamental hardware.
(I have no inside knowledge, my opinions are my own.)
I hope you don't like browsing the web…
Anything I should add?
It seems to me that extracting or injecting data that way is very hard to do, and is likely to return very little information.
Is the tradeoff something like: we should prevent the one in a hundred billion chance that my cpu leaks a critical password to some intruder one day at the cost of rendering all my processes 30% slower?
1) https://venturebeat.com/2019/05/14/intel-zombieload-flaw-for...
Really how much unnecessary complexity is traversing boundaries we can shut down or at least gate effectively?
My company has used CICS for this purpose since forever and we're not so much a legacy that you will think about our architecture in this way if we talked about it, but CICS is a very rare interface in this era.
30% slower for what? What workload? What environment?
I can’t even ask what your source on it being “worse than 30%“ because that statement doesn’t mean anything... people keep attaching percentages to these vulnerabilities that really mean nothing for any general use case, to the point you can’t even compare them to each other!
I imagine your answer is going to be “well these mitigations are going to be more slower than the last ones”
Do these vulnerabilities and the last live on the same hot paths?
Are you privy to some information we’re all lacking here that lets you just throw out a statement like this?
some more technical info here https://software.intel.com/security-software-guidance/insigh...
The tone of the original comment replied to definitely came from personal computing slant...
unless someone publishes a very practical attack from userspace, I don't think this will affect personal computing atm
If anything they’re asking the opposite! “Should we even be limiting the optimizations at all”
They start with the question “are manufacturers are forced to remove specific optimizations” (which replying to with “going to be worse than 30%” doesn't meaningfully answe) and immediately counter it with the above question “why remove any optimizations” (which your reply also doesn’t answer at all)
Calling out your arm wavy non-statement isn’t pedantry, asking that a comment be more than doomsaying noise isn’t either. Sorry if you feel otherwise.
> It wouldn't be impossible, but it's not something I will do: this isn't a problem to be solved by the OS, but by Intel or the user. The fdiv bug isn't a problem for most people, and for those that it is, it's more efficient to make the compiler do the bug work-around instead.
> Note that doing it in the kernel would mean trapping for every fp operation, and that's not good for a fp-intensive program: and the main programs which /would/ care about the fdiv bug are the fp-intensive ones.
https://groups.google.com/d/msg/comp.os.linux.development/4o...
Googling around it seems the typical solution, other than just doing nothing, was to recompile, as GCC had a patch to detect the FDIV bug and emulate division much more efficiently.
I only had a 486SX (no FPU) at the time so it was never really on my radar. Non-scientific software didn't really do floating-point arithmetic precisely because FPUs weren't very common on consumer hardware. Most of the people burnt by the FDIV bug were already well positioned to either recompile their software or receive patches from their vendors.
https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unsc...
https://en.wikipedia.org/wiki/Pentium_F00F_bug
OS vendors worked around it in software.
Can you imagine debugging this for that many months only to find out there was nothing on your end to fix.
Edit:typo fixed for pentium
Another confounding one was where I was trying to bulk copy some data to Sybase using Python. Started getting some really strange DB errors. Couldn't figure it out for a while. Turns out, it was a bug in the DB module and it was using uninitialized memory in certain conditions. Was a 1-line fix, but took about 6 weeks to find.
Yet another one was when I was working on porting my C++ services from 32 to 64-bit. Sockets were timing out immediately sometimes. Couldn't reproduce in the debugger. Was a bug in a 3rd party framework. It was improperly using the rtdsc instruction in some inline ASM. Worked fine on 32-bit, but the register layout was different on 64-bit. So, it was effectively reading a garbage upper 32-bits for the high-res timer. Only found that one because I noticed in my logs that my timers were reporting that some operations had taken >200 years. I forget how long it took to track that one down, but it was months of off and on hunting.
I've also hit internal compiler errors. The one I remember was that an anonymous namespace at global scope would cause an ICE. I was about to file a bug report once I'd a minimal reproduction, but it'd already been reported and fixed.
If lscpu still shows some offline cpus (let's say cpu 1 and 3 are offline), echo 1 >> /sys/devices/system/cpu/cpu<1 or 3>/online. Run lscpu again, and you should see all CPUs online and 2 threads per core.
Where are you seeing a performance burden? The spectre/meltdown patches had no impact to game performance: https://www.tomshardware.com/reviews/gaming-performance-melt...
Maybe it doesn't quite fit your criteria completely, since there is also a microcode workaround. Still...
They have a strong vested interest in pretending that sharing compute resources across customers is a safe thing to do, so they're unlikely to rock the boat.
I think very few mortals out there use SGX, Intel apparently dropping public tooling support for it just shows for it.
Biggest scare is coming to DRM users, but even they I think are not much impressed as insecure trustlets for 845 in the wild already made then to give up few years ago.
Of course the crumbs of many users can add up to a lot, so it's a still a concern, it's not really nothing.
Of course what matters is the PR involved, not the actual vuln. Hardware vulns are pretty bad since they can't be fixed. But still, it still sounds like worse than it really is.
Not sure how much of a risk this plays in that plan, though.
In all cases, Signal only uses SGX to improve cases where data previously was stored in plaintext. The idea is to change the required attack from "compromise signal servers" to "compromise signal servers _and_ compromise SGX".
which is of course exactly what sgx is supposed to defend against, but at the same time that kind of access is a pretty big problem on its own
Some people here (and elsewhere) have pointed out this recent tendency of Signal to put a lot of eggs in the same SGX basket. I hope they take a closer look at the risks of this strategy.
In short, who should be worried, a common Windows user, a *nix system admin or everyone who uses intel chips..
Direct connectivity (on Internet 1.0) seems to be playing with fire nowadays.
Security admins probably love the fact that they are guarding their assets from unknown threats/vulnerabilities that major manufactures have included in their products.
Or, as compute power, storage and hardware get less expensive, running two cryptoledgers for inbound and outbound communications would make it easier to sanitize every bit that enters a network.
I like squid and other products, but I think dropping TCP/IP from the LAN or tranfering all packets in amber (bitledger) would correct a lot of the present shortcomings with security, privacy and unfixable manufacturer defects.
Needing physical access to compromise a system sounds like a much better way to play whack-a-mole.
If the hardware cannot protect itself, moving the defense to the next layer out sounds plausible to me.
I made a blog post trying to explain the Intel ME hardware bug.
Understanding the Intel CSME Vulnerability for Mere Mortals - https://news.ycombinator.com/item?id=22534259