Intel deprecates SGX on Core series processors
edc.intel.com
edc.intel.com
Potentially, it would have had many use-cases in the DeFi industry, privacy-preserving computations, and so on. Looking a bit deeper though there were signs that placing all your trust in this technology was still a gamble. For example, the 'attestations' I spoke of earlier... were reports that had been signed by Intel's public key. You lose or hack that key and suddenly you can spoof reports. Then there were the hardware exploits which was the nail in the coffin.
It's sad really because Intel SGX was some innovative shit. It would have enabled applications that just aren't possible with a conventional computing model. But it was too good to be true, unfortunately.
In my opinion, it's a huge risk. With a regular blockchain, the fact that someone might maliciously be running the wrong code is baked into the design, and the security model has to handle it.
With SGX, you are relying on Intel's security model to make sure everyone is running the same code. If SGX is ever broken (which it has been, to some extent) and a malicious node is running different code, then your whole security model falls apart and they can start attacking the blockchain.
You might argue that you can design the blockchain to be secure even when SGX is broken. But if it's secure enough without SGX, why use SGX? You risk your security model being broken due to a bug and nobody realizing due to SGX protecting it, until SGX stops protecting.
Plus, you exclude people who don't have SGX from running your blockchain.
That may be MobileCoin[0].
Before that, from the same inspiration, Signal built SVR[1], a recovery system for the address book that uses SGX to ensure the servers cannot decrypt the backup.
I wonder how they will react to this deprecation.
[0]: https://developers.mobilecoin.com/overview/security/secure-e...
[1]: https://signal.org/blog/secure-value-recovery/#deus-sgx-mach...
The trade offs between zk and hardware accelerated encryption still lean towards hardware though I’m not sure how much longer that will be true. It’s very difficult to imagine a general purpose ZK machine, but you don’t need general purpose compute to get most of the value out of defi as it exists today.
In short, we’re 5-10 years away from the first general compute zk machines/vm’s imho but bespoke zk circuits are starting to appear for many use cases. Checkout plonky2 as a cool example of a modern fast zk circuit, the polygon team is doing great work here.
We’ve been working towards a fully zk winterfell implementation/proposal but it’s not there yet.
In closing, one of the unique things in mobilecoin is private information recovery at scale using MobileCoin fog (https://mobilecoin.com/news/fog-foward-in-oblivious-computin...) which isn’t possible with any zk circuit I’ve ever seen (due to the need to store lots of information durably with fast access that doesn’t leak access patterns to the server).
I wonder whether we can have our cake and eat it too; are there plans for FPGA-accelerated ZK machines?
Original info: https://azure.microsoft.com/en-us/blog/announcing-microsoft-...
Some of the current outcomes:
https://azure.microsoft.com/en-us/services/azure-confidentia...
My consern is that it hasn't been tested as a generic proof of stake network and there is a risk that it might not degrade as expected.
It also means the blockchain can't be independently verified. If someone was to exploit it in a way that gave themselves extra coins, then nobody would ever know because all evidence is hidden inside the secure enclave.
How big is the risk? I'm not sure. I just suspect it's bigger than the advantage you get from using SGX; There are other ways to get privacy.
I think the answer is that you're never really sure that your defense is perfect, and that's true of both SGX and byzantine algorithms.
It is alive and the source code is shared.
Doesn't that trust fall apart when the SGX has known hacks?
eg bad actors can do their thing
...Or are you just using the word "blockchain" to literally mean a Merkle tree, so that the "innovation" was equivalent to storing settlements in git?
Companies like Google now have employees issues with Yubikeys [1].
[1] https://www.yubico.com/resources/reference-customers/google/
https://community.intel.com/t5/Blogs/Products-and-Solutions/...
edit: as for why this is bad, federal law enforcement have a lot more pull when seeking change in laws in congress. Maybe Apple would've had to implement a government backdoor into iPhone itself if they didn't pull the CSAM scanning stunt (and I imagine they knew the backlash was inevitable, which allowed them to use that backlash as reason to push back on either scanning or a backdoor).
Apple never used the excuse they want to do end to end encryption, did this changed recently? because as far as I know only fanboys used this excuse pulled out of the air. This fanboys always have the most shit excuses like "if Apple let' s you do X what if some child does X while walking and falls in a hole, then Apple will look bad", fanboys really hurt every time their favorite company looks bad in the news see how fast some bad news gets down-voted here on HN(Tesla, MS news too from what I noticed, you start to add a comment and in 1 minute the article is gone from the first page or even flagged)
0: https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
1: https://blog.elcomsoft.com/2021/01/apple-fbi-and-iphone-back...
Google and FB reported a lot more CSAM then Apple so far, so what do Apple fans think
1 Apple users have less CSAM then Google/FB users
2 Apple users use Google for CSAM, maybe those services are better qwuality or for what they use it for
3 Apple never cared about CSAM and did the minimum work possible, and they never care for CSAM now either but for some reason they needed this backdoor scan and report process to always run on devices.
4 some other reason, maybe Apple users are not into this shit, keeping in mind Apple is anti adult software on their devices , some people would avoid their censored devices
The industry has been pushing for copyright enforcement built into the hardware and OS. Windows 10/11 is the first client-server OS, aka the ultimate security risk since you all have been stealing software from yourselves with the rise of mmo's and steam, there's ZERO reason for any piece of software to require an internet connection.
Intel, MS, Sony and AMD are not going to give up on trusted computing. They want to remove control of our PC's to jack up software prices and force the public to pay for software and games.
What will happen when the Gracemont small cores will be replaced at the end of 2023, is not known yet.
It is still possible that the successor of Gracemont will have AVX-512, in which case the Intel processors with "Hybrid Technology" will also have it, at that time.
Taking into account that Zen 4 is expected to have AVX-512, it is unlikely that Intel has not also planned for Meteor Lake (2023) to have it. Meteor Lake is supposed to be made using a more dense CMOS process than Alder Lake and Raptor Lake, which should enable Intel to implement AVX-512 in the small cores.
But worst case scenario of the OS moving the process to a big core on an illegal instruction or scheduling it to the right core based on a required capabilities system would also be quite acceptable most of the time.
Plus, it'd be great for supporting more specialized cores designed for different purposes and running a single core ISA with extensions for their specific needs. IIRC, there are some ARM chips that have three different kinds of core.
Also note that it wasn’t well received 2 years ago. Example: https://news.ycombinator.com/item?id=23809335
This is bad with dGPUs over the PCIe bus, but not so much with GPUs that share a very fast memory bus with the CPU. In this case, the layout of the data may prove challenging to keep the same for when you use a CPU and a GPU.
For 64-bit keys, we sort about 1 GB/s per (5 year old) Skylake core, and perhaps 5-6 parallel.
This (2018) reports 3.5 GB/s: https://benkarsin.files.wordpress.com/2018/10/dissertation.p... And a 6-year old GPU radix sort reports 2.1 GB/s: https://github.com/Bulat-Ziganshin/Compression-Research/tree...
BTW I've worked on a product that used GPUs. That typically requires everything to move to the GPU, which is not always desirable or feasible.
https://dev.to/tishden/computing-with-gpu-why-when-how-and-s...
This shows a approximately 20x speedup (2021, graph 1 vs 3): https://www.irjet.net/archives/V8/i7/IRJET-V8I7714.pdf
The "25-fold speedup", as is often the case for such reports, comes from not optimizing the CPU side.
Have you seen the state of GPU software development? GPUs are very expensive in cloud, are poorly supported in containers and virtual machines If you want to use GPU compute, some stuff is Nvidia-only, some stuff is glitching and crashy, it's probably not avaliable in your language of choice, etc.
It is literally impossible for me to add GPU compute to any of our corporate workloads, but I can tap into AVX easilly in my language of choice.
I'm pretty sure GPUs closes that gap over time though.
This throws upside down the whole x86-64 levels concept. What a mess.
[0]: https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-x...
https://www.tomshardware.com/news/intel-nukes-alder-lake-avx...
As a security researcher and given past showings from Intel, I wouldn't put much faith in SGX, even if they try to fix past flaws. SGX as a concept for tenant-provider isolation requires strong local attacker security, which is something off the shelf x86 has never had (not up to contemporary standards, ever) and certainly not in anything Intel has put out. They've demonstrated they don't have the culture nor security chops to actually engineer a system that could be trusted, IMO. Plus then there's all the microarchitectural leak vectors with a shared-CPU approach like that, and we know Intel have utterly failed there (not just Spectre; there was absolutely no excuse for L1TF and some of the others, and those really showed us just how security-oblivious Intel's design teams are).
Right now, the x86 world would probably do well to listen to Microsoft, since their Xbox division managed to coax AMD into actually putting out secure silicon (they're one of the two big companies doing proper silicon security at the consumer level, the other being Apple and Google trying to catch up as a distant third). But given the muted response to Pluton from the industry, and the poor way in which this is all being marketed and explained, I'm not sure I have much hope right now...
I generally agree with you. But I recently realized there might be one usecase, and it's pretty much what signal is doing. They're processing address books in SGX so that they can't see them. I don't have much faith in the system because I don't trust SGX, of course.
But there is one interesting aspect to this. If anyone comes knocking and tells them to start logging all address books and hand them over, they can say that it's not possible for them to do so.
Anyone wanting to do that covertly would at least need to bring their own SGX exploits, meaning it probably offers SOME level of protection. Certainly not if the NSA wants the data or some LEA is chasing something high-profile enough that they're willing to buy exploits and get a court order allowing them to use them. But it does allow them to respond with "we don't have this kind of data".
It's become a moral cause to make a lot of big-data computing deniable, to be data-oblivious. This is a responsible way to build an application, is well-built security, and I like it a lot.
I agree this work is important and enclaves are better than nothing though.
We've literally built a new web crypto platform where we favor 100% the vile fucking cloud fuckers for all computation rather than the client, which seems as fucked up horseshit backwards trash city dystopia as could be possible. Everything is backwards & terrible.
That said, we 100% cannot trust most user-agent sessions, which are infected with vast vast spyware systems. The web is so toxic about data sharing that we have to assume the client is the most toxic agent, & make just the host/server responsible. This is just epically fucking fucked up wrong, & pushes us completely backwards from what a respectable security paradigm should be.
In most places, end-to-end security is the goal. But we've literally built the web crypto model to ensure the end user reaps no end-to-end benefit from web cryptography.
The alternative would be to trust the user-agent, to allow end-to-end security. But we don't allow this. We primarily use crypto to uniquely distinctly identify users, as an alternative to passwords.
This is a busted jank ass sorry sad limited piece of shit way for the web to allow cryptography in the platform. This is rank.
The Nitrokey security key people saw this huge gap, & created a prototype/draft set of technologies to enable end-to-end web encryption & secure storage with their security keys. https://github.com/Nitrokey/nitrokey-webcrypt
https://www.usenix.org/system/files/conference/usenixsecurit...
The basic idea is that you can play with the clockspeed and voltage of one ARM core using code running on the other. They used this to make an AES block glitch at the right time. The cool part is that, even though the key is baked into the processor, and there are no data lines to read the key (other than the AES logic), this lets them infer the key.
Hmm. The paper is 5 years old. I still think we are a decade away.
It's also how I pulled the keys out of the Wii U main CPU (reset glitch performed from the ARM core). Heh, that was almost a decade ago now.
That's why Apple uses a dedicated SEP instead of trying to play games with trust boundaries in the main CPU. That way, they can engineer it with healthy operating margins and include environmental monitors so that if you try to mess with the power rails or clock, it locks itself out. I believe Microsoft is doing similar stuff with Xbox silicon.
Of course, all that breaks down once you're trying to secure the main CPU a la SGX. At that point the best you can do is move all this power stuff into the trust domain of the CPU manufacturer. Apple have largely done this with the M1s too; I've yet to find a way to put the main cores out of their operating envelope, though I don't think it's quite up to security standards there yet (but Apple aren't really selling something like SGX either).
"SGX as a concept for tenant-provider isolation requires strong local attacker security, which is something off the shelf x86 has never had"
Off the shelf CPUs have never had anything like SGX, period. All other attempts like games consoles rely heavily on establishing a single vendor ecosystem in which all code is signed and the hardware cannot be modified at all. Even then it often took many rounds of break/fix to keep it secure and the vendors often failed (e.g. PS3).
So you're incorrect that Intel is worse than other vendors here. When considering the problem SGX is designed to solve:
- AMD's equivalents have repeatedly suffered class breaks that required replacing the physical CPU almost immediately, due to simple memory management bugs in firmware. SGX has never had anything even close to this.
- ARM never even tried.
SGX was designed to be re-sealable, as all security systems must, and that more or less has worked. It's been repeatedly patched in the field, despite coming out before micro-architectural side channel/Spectre attacks were even known about at all. That makes it the best effort yet, by far. I haven't worked with it for a year or so but by the time I stopped the state of the art attacks from the research community were filled with severe caveats (often not really admitted to in the papers, sigh), were often unreliable and were getting patched with microcode updates quite quickly. The other vendors weren't even in the race at all.
"there was absolutely no excuse for L1TF and some of the others, and those really showed us just how security-oblivious Intel's design teams are"
No excuse? And yet all CPU vendors were subject to speculation attacks of various kinds. I lost track of how many specex papers I read that said "demonstrating this attack on AMD is left for future work" i.e. they couldn't be bothered trying to attack second-tier vendors and often ARM wasn't even mentioned.
I've seen some some security researchers who unfortunately seemed to believe that absence of evidence = evidence of absence and argued what you're arguing above: that Intel was uniquely bad at this stuff. When studied carefully these claims don't hold water.
Frankly I think the self-proclaimed security community is shooting us all in the foot here. What Intel is learning from this stuff is that the security world:
a. Lacks imagination. The tech is general purpose but instead of coming up with interesting use cases (of which there are many), too many people just say "but it could be used for DRM so it must die".
b. Demands perfection from day one, including against attack classes that don't exist yet. This is unreasonable and no real world security technology meets this standard, but if even trying generates a constant stream of aggressive PR hits by researchers who are often over-egging what their attacks can do, then why even bother? Especially if your competitors aren't trying, this industry attitude can create a perverse incentive to not even attempt to improve security.
"the x86 world would probably do well to listen to Microsoft, since their Xbox division managed to coax AMD into actually putting out secure silicon"
SGX is hard because it's trying to preserve the open nature of the platform. Given how badly AMD fared with SEV, it's clear that they are not actually better at this. Securing a games console i.e. a totally closed world is a different problem with different strategies.
Except that was an afterthought. Originally only whitelisted developers were allowed to use SGX at all, back when DRM was the only use-case they had in mind.
The whitelisting was annoying but gone now. The justification was (iirc) a mix of commercial imperatives and fear that people would use it to make un-reversable ransomware/malware. SGX was never really a great fit for copy protection because content vendors weren't willing to sell their content only to people with the latest Intel CPUs.
[0] - https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthen...
[1] - https://www.intel.com/content/www/us/en/developer/articles/t...
[2] - https://azure.microsoft.com/en-us/blog/azure-and-amd-enable-...
I think the biggest contribution that cloud providers can bring to the table in the mid-term is mitigation of the physical attack vector. This would involve inserting themselves as a second root of trust in attestations (SEV has explicit support for this), which would mean that a real world attack would require collusion of multiple parties (pick 2 of Hardware vendor, Cloud provider, Software vendor).
SGX and TEEs generally are and always were a DRM solution, with the server use-case mostly being an afterthought that the marketing teams pushed hard. They also create a fantastic forced-obsolescence program as they require active support on the part of chip makers throughout an application's lifecycle; Intel can arbitrarily deprecate otherwise functional CPUs by just not revoking compromised keys (and perhaps releasing a few into the wild just to force people to upgrade).
IMHO that is still a bad thing because it violates some fundamental principles around what ownership really means.
Of course if you're inside the hypervisor and being software emulated, it could do anything to you. The idea is you verify enclaves remotely, so no other system would want to talk to your software emulator and share it secrets.
You can mess with your local copy of the enclave, but then no one else will be able to verify it remotely (because the Intel CPU won't sign it like you need it to)
And the main limitation of this approach is that it's really hard to prevent breaking a single cpu from being a class break.
You manage with glitches or side channels (e.g. spectre for sgx) to steal the per cpu secrets, and then you setup an emulator that can obtain intel attestation, then suddenly any application that depends on the impossibility of an emulator faking that attestation is broken.
It's even harder for these DRM-focused SGX like solutions because they really need the attestation to be anonymous to avoid it being a massive tracking vector and privacy breach... while a more traditional hsm attestation would still identify the device and potentially allow limiting the impact of compromising a single one.
Presuming you can only learn the CPU's ID through through the VM itself, then an attacker with access to the hypervisor, plus at least one private key extracted from a sacrificial CPU of the same model, could just have the VM report the extracted-from CPU's serial number, and then use the respective extracted private key in their SGX enclave emulation. And this would check out with Intel.
Or, of course, a lot more simply, you could just make up your own keys instead of extracting any Intel keys, and then have the VM rewrite any Intel CPU root certs it finds in the VM's memory to be the attacker's certs instead (and any hashes of those certs be the hashes of the attacker's certs, etc.); such that messages signed by fake-SGX validate within the VM, and messages encrypted by fake-SGX decrypt within the VM, and messages encrypted by the VM decrypt within fake-SGX. In other words — don't keygen the user's workload; crack it. The SGX enclave is very rarely used in such a way where the component checking it is running on anything other than the same VM calling into it, so why bother worrying about what other untainted machines communicating with the enclave might see? That'd be like worrying about what more-sensible third-parties might tell your victim in a confidence scheme.
I think their best answer is a sort of blacklist system where if Intel becomes aware one of their key has leaked, their servers could stop telling people it is genuine (this gets into the details of EPID and DCAP that I really don't want to clutter my memory with, so my retelling may be less accurate there)
To prevent the idea with fake certificates, I think you "simply" pin some Intel root certs in your enclave. Do TLS with those, verify the "TCB" cert chain with them too. Then the VM either lets you run on a real CPU and cannot poke your encrypted memory, or it emulates you and this is back to the previous scenario (it owns you locally, but remote attestation fails)
The whole thing that makes SGX interesting and not a boring traditional HSM is remote attestation for secret provisioning, sealing of secrets, etc. This means you in theory run workloads on someone else's computer without having to trust it. If your secrets are already on the attacker-controlled VM and you only verify things locally, this is useless. Nothing can save you, the VM already owns your entire environment.
I don't know what this means for 4K Netflix, if anything.
Oh well. Maybe some other company will build hardware transactions in a way that takes developer feedback into account.
Crosspoint DIMMs had an analogous problem. There was no way to pin a cache line for updates, so that it couldn’t spill to persistent storage mid page update. Some cool workarounds came out of the research community, but, in the end, that technology is dead on arrival too.
If you look back at so many of the intel architectural extensions it is so hard NOT to draw the conclusion that Intel has a POOR understanding of where problems should be solved. They constantly try to solve problems which should be solved in software with hardware. This is why they are now an architectural generation behind AMD and why they are most likely going to lose the CPU market to Apple imitators.
Unless AMD can maintain its success despite the talent bleed it will start to face — the days of x86 are limited.
While CHERI is, from a pure theory standpoint, something that is perfectly avoidable with proper programs (i.e. memory unsafety _is_ efficiently avoidable in software), we ended up needing it we made the wrong choice in software too long ago to turn back (nobody is rewriting the Linux kernel anytime soon). In this way, CHERI is a good optimization because it does something we cannot _practically_ solve in software. ARM-PA plays a similar role in that hardware CFI can be made irrelevant by a) not having memory safety issues b) software CFI, but neither have really worked out in practice and it's cheap and efficient in hardware, so it's a worthwhile tradeoff.
Stuff like Intel TSX and ARM TME are sort of at the other end. Transactional memory is _super_ cool and it's been a common thread throughout architecture papers for the past twenty years. The thing is, we've never had transactional memory in commodity hardware (and nobody buried their heads in the sand about not having it like we did with memory safety) so all our software found decent work arounds eventually. TSX/TME does do what it says, the issue is just that it's not quite good enough when compared to existing software techniques and so the actual added value (cache noise and the resulting spurious aborts included) made it a less good deal. When adding the cost to both update software and the likely strongly polynomial (?) hardware cost of transaction support as core count grows (this is why ARM's Exclusive Monitor performs SO bad on systems with 64+ cores and why they added new atomics just to avoid the monitor), it just doesn't work anymore.
Transactional memory is one of those things that constantly sounds like it's a good idea in theory, but it doesn't live up to those ideas in practice. One of the issues with hardware transactional memory is the challenge of spurious aborts or otherwise running up against hardware limits as to how big transactions can be. Another (as far as I'm aware) unsolved issue is defining a memory model that supports both transactional memory and the modern C/C++ memory model. I also don't think there's a lot of practical benefits--you can make it quite far with existing parallelism libraries that expose something vaguely task-based or fork-join, such as OpenMP or STL's parallel executors, and there's relatively little need for algorithms where you don't necessarily know if there's going to be contention or not.
Of course retrofitting such a feature into C/C++ in a satisfactory manner might not be possible. But the practical benifits are real.
The bigger problem was actually that in many cases where the optimization could be applied there was always a conflict, usually because of updating some sort of statistical counters. So a lot of attempts to optimize this way would de-opt. It could be fixed by changing the way stats were aggregated to be more tx-friendly but few developers ever did it.
Same question here, As usual, no reasons are given (must admit I'm getting sick of these corporations failing to explain their actions). Right, I'm old enough to remember when companies used to issue detailed revisions sheets/documentation wherein they described what the changes were and the reason for them just as a matter of course.
(Even after being an unwilling member of the users' mushroom club for some 20/30 years, I'm still having difficulty adjusting.)
Edit: There is another comment linking an article from Intel saying SGX is full steam ahead in Xeon. Yay my thesis is not useless!
After several of those "Release, revert" cycles, it ends up as a self fulfilling prophecy anyway - it's like the sentiment towards Google's new products you see often: "This, too, shall rapidly pass when they get bored." After you've seen TSX disabled on a few generation of chips, the motivation to put the work in to make something work with TSX just kind of evaporates, because you've no confidence that it'll actually work, or stay working, on hardware you want to run on. And because of the requirement to have a fallback path, TSX is a good bit more work, and, often, requires more complexity than a simple lock based approach that's good enough and simple to understand/validate.
But my deeper concern is that it seems that nobody at Intel is capable of understanding all the interaction in the chip anymore - and SGX offers very strong evidence of this inability.
SGX made the strong claim that, when deployed, a fully malicious ring 0 operating system could neither observe anything about the state of the compute happening in the enclave, nor modify the operation of that. They did various interesting things with how pages were swapped out to prevent replay attacks, and really did try to build it such that you couldn't mess with it. But they did these things at a high level, and didn't fully understand the nature of the chip.
The L1TF (L1 Terminal Fault, also known as Foreshadow) attacks took advantage of the edge case L1 cache behavior to speculate out out anything that was in L1 cache, which included SGX enclave data. If I remember properly, because you could read out the stored register state as well as memory pages you faulted in, they demonstrated you could essentially single step a production SGX enclave with full register state and full memory state at every single instruction. Whoops.
It's not hard to mitigate once you know the problem - just flush L1 entirely on exit. But Intel didn't know it was a problem, so they didn't do that.
On the flip side, "influencing operation," there was Plundervolt. This involved the OS using an undocumented (grumble growl) MSR to reduce the voltage of the chip for improving efficiency of operation. However, the OS (that untrusted ring 0 thing...) has control over this register. And there aren't sane limits on it, such that the OS can drop the voltage enough that things like "multiply" and "AES operations" start faulting and glitching (silently), without being low enough that the chip stops functioning. Enter an enclave in this state, wait for multiply or AES to fault in the useful ways they will, and you've just influenced operation such that you can pull keys out. Whoops.
Again, it's not hard to mitigate. Refuse to enter if the voltage isn't at stock settings (you can't just reset it on entry because it takes time for the VRMs to bring the voltage back up). But Intel didn't do this. The people who added this neat little efficiency hack and then kept it secret never rubbed the right way with the people in charge of the new flagship security features around the sort of adversarial thinkers who can ask "Now, wait a minute, what if I push this beyond sane bounds?"
You can point at the other speculative stuff and claim it's not really a problem because architectural behavior is correct (I think that sort of reasoning is rubbish, when you can speculate your way past all security boundaries on the chip), but the SGX case, specifically, demonstrates that Intel didn't know about the problems or they would have taken the very simple mitigation steps. And that tells me that they can't reason about their chips as a whole.
... and that - hardware companies of the most critical components of the system not having a full understanding of how they operate - is scary. The foundation of everything is in an unknown state, and nobody knows how broken it is until some researchers go in and figure it out.
More than once, after fixing the exact thing the researchers found, Intel has also had egg on their face of the "... so we found this very, very closely related, conceptually identical bug that they didn't fix with the last patches..." variety. It seems safe to say that there are university students and faculty who understand the security implications of Intel's design decision better than the people at Intel in charge of such things.
We're running, very rapidly, out of "complexity runway." Everything, from the very chips on up, is so complex that nobody can reason about it, and the only solution to the very problems caused by complexity is, "Well, let's add more complexity to fix those problems." It's not the sort of thing that can go on forever.
Anyway. </rant about the state of Intel>
The ring boundaries of protected mode were never meant as a strong security feature against malice. The documentation of the 286, the first CPU in which they were introduced, is very clear in saying that. It's unfortunate how many assumed otherwise and built an entire industry upon that misunderstanding.
I don't know how to fix it, though.
I've been experimenting with Qubes lately, which disables hyperthreading if you have it, and uses hardware isolated VMs to at least make things a little bit harder - the assumption is that within a running OS VM/silo, anything can access anything, so keep them separated. And they've done a lot of good paranoid work along those lines. I'm just not sure the end goal of very strong isolation is even possible on the same machine.
Of course, there are chips that are immune to speculation based vulnerabilities. They're not fast, and they're not very modern, but the Atom D525 in my little netbook has an empty "bugs" field in /proc/cpuinfo, because it's an in-order, non-speculative x86 core. It's just rather glacial.
But also, this process of "we got it, wait we didn't..." is just how real world security works, there is no way around it. Security is not <clever research team coming up with moon math> and problem is solved. Security is complex, and takes years of attack incentives and hardening to mature. TLS implementations can use the best crypto algorithms we know of, and we still get Heartbleed. Intel already with the very first release of SGX introduced the TCB recovery mechanism, precisely because they knew users are bound to find vulnerabilities.
There is also a strong hysteresis effect because of the long release cycle of chips. For example, SGX was released in 2015/2016 with Skylake, and then two years later we discovered Meltdown/Spectre and with them a whole new dimension of attacks on the CPU. However, Intel couldn't just release a hotfix for their hardware, it took a lot of time and work to re-design the CPU to be more side-channel resistant, and in the meantime security researchers naturally latched onto these attacks, giving the false impression that the whole idea of secure compute is flawed.
Personally I would not bet on CC tech becoming obsolete, on the contrary, a lot of Big Tech are pumping more and more resources into it, and there is increasing demand from various industries. The tech will stay around, it will mature, and perhaps vendors will even start to introduce HSM-like hardware protection mechanisms if there is enough demand.
What was wrong with it? It seemed to offer such massive performance benefits for complex multithreaded code.
While it was buggy, Intel doesn't seem keen in bringing in a replacement.
I was waiting till next Ubuntu LTS to have qemu packaged with SGX support in order to reverse engineer my fingerprint sensor (which is match-on-host, and uses SGX under Windows).
Only that which is solid and the board can agree on becomes a ratified specification. The instruction counts are still sane[0], despite it is not missing anything of significance which ARM or x86-64 have anymore, as of the group of extensions that were ratified late 2021.
Just because it is too young for that to have happened yet doesn't mean it can't.
What would be the difference between deprecating SGX on Intel and a similar technology on a RISC-V based chip?
His only danger at this point is jail.
don't they say the chat is end to end encrypted?