17 ms·
New flaw in Intel chips lets attackers slip their own data into secure enclave
- pengaru 7y agoalso https://www.zdnet.com/article/intel-cpus-vulnerable-to-new-lvi-attacks/ https://www.zdnet.com/article/intel-cpus-vulnerable-to-new-l...
- popotamonga 7y agoI wonder what would happen if a flaw were found that would render an entire line of expensive CPUs useless.
- metalliqaz 7y agothe closest I can think of was the famous floating point error that caused Intel to recall lots of parts[1]. Even that didn't render the CPUs useless for most users, only some scientific and business use cases really had problems. [1] https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug
- NortySpock 7y agoAnd as I recall Linux had a kernel patch that would bypass the affected hardware and run all floating point operations in software (splitting floats into two integers, etc), so you could bypass the flaw at the cost of performance.
- wahern 7y agoI remember Linux having floating-point emulation for 486 processors without a floating point unit. But at least according to this early message from Torvalds, Linux didn't implement this for FDIV: > 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/4o75FKT7Ng4/_OeHY8a-yWkJ 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.
- flatiron 7y agonot OP but i always assume Linux had a workaround. But you are right, it just prints you got the bug and that's that https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unscoped_q=X86_BUG_FDIV https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unsc...
- __jal 7y ago"Render useless" makes me think of something more like the F00F bug - hard lockup until a reboot. https://en.wikipedia.org/wiki/Pentium_F00F_bug https://en.wikipedia.org/wiki/Pentium_F00F_bug OS vendors worked around it in software.
- alex_free 7y ago>Thomas Nicely, a professor of mathematics at Lynchburg College, had written code to enumerate primes, twin primes, prime triplets, and prime quadruplets. Nicely noticed some inconsistencies in the calculations on June 13, 1994, shortly after adding a Pentium system to his group of computers, but was unable to eliminate other factors (such as programming errors, motherboard chipsets, etc.) until October 19, 1994. On October 24, 1994, he reported the issue to Intel. Can you imagine debugging this for that many months only to find out there was nothing on your end to fix.
- 2J0 7y agoMy memory is hazy but I'm sure I recall the problem during summer 94, but I stand corrected. Was there any normal way for the information to reach us? That was the year intel took down Vlsd Pentkovskis profile page.. I loved to tease everyone that Pentium was named tribute to him... Edit:typo fixed for pentium
- sarah180 7y agoI had a similar experience when doing my first serious work in a compiled language. I found and reported a compiler bug in double-precision division (in a commercial C compiler). It took me years to stop blaming the compiler for my bugs.
- snovv_crash 7y agoI had the same, an embedded system with GCC 3.something. Managed to get a toolchain together with 4.something and suddenly our uptime and random corruption issues disappeared.
- hermitdev 7y agoI spent an entire summer as an intern, constantly on the phone with IBM support trying to get DB2 Connect to work in a Windows cluster only to be told "this is not a supported configuration" despite it being clearly supported in the documentation. Gave up. Years later, ran into my former boss randomly (at a liquor store of all places) and he mentioned they were finally able to get it to work. 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.
- brenden2 7y agoIntel has already had so many flaws and vulnerabilities that I think nothing will change. People would prefer to ignore the problem and do nothing because they don't want their businesses to implode.
- metalliqaz 7y agoI wish the updates for Spectre/Meltdown were optional on my Windows machine. They posed no real risk to my single-user gaming machine and the fixes had an unacceptable performance burden IMHO.
- swift532 7y agoAre you sure they are not optional? I remember disabling various security updates at the time, but unfortunately I wasn't testing whether performance in games was affected positively after removing them. I can only say that it felt as it had been faster, but I hadn't measured FPS.
- metalliqaz 7y agoMy understanding is that newer Windows version contain microcode updates for the processors, and once they are applied, they are in there for good.
- mgiampapa 7y agoMicrocode doesn't flash the CPU, it's loaded at boot time, you can remove it and disable the software mitigation.
- agloeregrets 7y agoSame on my Chromebook Pixel LS too. They were optional but now they added all kinds of additional mitigations and are also adding linux throttling and in the last 6 months or so I probably have gained ~60% compile time.
- atq2119 7y agoPeople patch, or seriously consider patching, their compilers -- unfortunately. See for example: https://bugzilla.mozilla.org/show_bug.cgi?id=1596565 https://bugzilla.mozilla.org/show_bug.cgi?id=1596565 Maybe it doesn't quite fit your criteria completely, since there is also a microcode workaround. Still...
- 2J0 7y agoSeriously this isn't humor, we're running a "abandoned " processor for authentication and a operating system decidedly unattractive unless you want to win capture the flag at deacon. We abandoned the secure operating system version very reluctantly so it was formerly B book.
- saagarjha 7y agoI’m having difficulty understanding this comment, would you mind explaining it a bit more?
- kijiki 7y agoThe driver for recalls is demand from the largest customers. In Intel's case, mostly big cloud operators. 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.
- sf_rob 7y ago[Ignorant tangent] Is core hardware more exploited these days or are vulnerabilities just more reported in tech news? I'd assume the former, but I'm not a hardware person. If so is this just due to increasing complexity/optimization going on in chip design or better tooling/methods of exploitation?
- josh2600 7y agoAs far as I know there has never been an enclave attack found in a rootkit in the wild. This is probably because there hasn't been anything publicly obviously worth stealing in an enclave yet.
- sulam 7y agoReally? Credit card tokens aren't valuable enough? Device-specific private keys? These secure enclaves are routinely used for extremely sensitive data, surely it's more worth stealing than someone's WiFi credentials.
- josh2600 7y agoIt’s not obvious to me that credit card tokens are fungible enough (or stored in SGX). They’re also a highly insured asset with manageable counterparty risk. 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.
- gowld 7y agoNot really, because if your device is owned, they can read your credit card info from the main OS environment. Secure enclave us really about protecting the device from being stolen and taken over, not protecting important secrets. 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.
- sulam 7y ago
- d--b 7y agoDo all these vulnerabilities mean that manufacturers will have to remove those optimizations, rendering the cpu slower? 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?
- rishabhd 7y agoI think it already happened, where the flaw itself was critical and the performance impact was substantial. See Zombieload for reference. 1) https://venturebeat.com/2019/05/14/intel-zombieload-flaw-forces-os-patches-with-up-to-40-performance-hits/ https://venturebeat.com/2019/05/14/intel-zombieload-flaw-for... 2) https://zombieloadattack.com/ https://zombieloadattack.com/
- 2J0 7y agoCan I restate the go question as "is complexity of the machine effectively security by obscurity and effective in practice for reliance upon?" 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.
- ghaff 7y agoWe call it serverless now :-) (I'm joking a bit but there are similarities.)
- gameswithgo 7y agoGoing to be worse than 30% slower by a lot.
- BoorishBears 7y agoWhat does this statement even mean? 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?
- aibrahem 7y agoThis is a shameless plug, but I'm really hoping to increase the awareness and the level of understanding about these kind of HW bugs. 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 https://news.ycombinator.com/item?id=22534259
- the_duke 7y agoCould we change the link to the source? https://lviattack.eu https://lviattack.eu It has a good explanation, videos and FAQ. (the Techcrunch post is just horrible)
- mzs 7y agoI concur, it also links to the paper and repo https://lviattack.eu/lvi.pdf https://lviattack.eu/lvi.pdf https://github.com/jovanbulck/sgx-step https://github.com/jovanbulck/sgx-step
- saagarjha 7y agoAnd a trailer! https://www.youtube.com/watch?v=baKHSXeIIaI https://www.youtube.com/watch?v=baKHSXeIIaI
- deleted 7y ago[deleted]
- TekMol 7y agoI often think Techcrunch should be banned on HN. 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: https://news.ycombinator.com/item?id=22539255 https://news.ycombinator.com/item?id=22539255
- mzs 7y agomuch better link https://lviattack.eu/ https://lviattack.eu/
- bayindirh 7y agoI'm considering to upgrade my primary computer this summer and considering an AMD system. Following is my thought process: - 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...
- mynameisvlad 7y agohttps://www.techspot.com/news/84309-amd-cpus-vulnerable-severe-new-side-channel-attack.html https://www.techspot.com/news/84309-amd-cpus-vulnerable-seve... From 2 days ago, in case you weren't aware.
- temac 7y agoThe "new" AMD attack depends on lack of already existing spectre mitigations. If I understand correctly, this one is a real new one that works against a correctly patched system.
- cosmiccatnap 7y agoYou are correct. No AMD vulnerability is in the same universe as the Intel vulnerabilities from this year alone. Good luck on your new build
- afiori 7y agoCuriosity: is this down voted because it is false/exaggerated? As someone that is far from being an expert I would be interested in a counterexample
- saagarjha 7y agoI think the current outlook on this is "the only reason we're not seeing speculative bugs with AMD is because nobody is looking and they're probably more annoying to find", not that they're not there.
- olah_1 7y agoSignal is planning on using Intel's SGX enclaves. https://signal.org/blog/secure-value-recovery/ https://signal.org/blog/secure-value-recovery/ Not sure how much of a risk this plays in that plan, though.
- kijiki 7y agoSignal already uses SGX for Contact Discovery, and has for many months. 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".
- AndrewBissell 7y agoOK, but if compromising SGX is pretty easy, that just leaves the servers (hosted on AWS) for someone to be able to observe and decrypt all Signal traffic, right?
- v4dok 7y agoIt is anything but easy. I guess that is why you get downvoted. The fact that only this academic group was able to come up with these attacks shows the amount of knowledge you need to have to carry them out.
- AndrewBissell 7y agoOK, but how hard is it for a state-backed intelligence agency to come up with that knowledge? The Vault 7 leaks showed that the CIA has all kinds of very deep capabilities in this area. I'm not thinking of some random script kiddies doing this.
- v4dok 7y agoPast news should have shown that pretty much nothing is invulnerable from state-backed intelligence services. I would be more worried about what can realistically be hacked by random people on the internet.
- guerrilla 7y agoIf anyone's interested, I recently started a youtube playlist collecting talks on exploiting and securing x86 hardware and firmware: https://m.youtube.com/playlist?list=PL7Jsn37GlvSwYGaetkukEROk9Ew8OUoHj https://m.youtube.com/playlist?list=PL7Jsn37GlvSwYGaetkukERO... Anything I should add?
- Lind5 7y agohttps://www.youtube.com/playlist?list=PL4RrBxLcT1nZThUvIFjS0cuR1REb_ZDJJ https://www.youtube.com/playlist?list=PL4RrBxLcT1nZThUvIFjS0...
- remind_me_again 7y agoExcuse my irrelevant question, but I can't hold myself to ask. Why do they think it's a flaw but not an intentional mistake to open a backdoor to government agencies?
- totaldude87 7y ago[security noob here]can anyone explain this in layman terms, i.e can these be exploited remotely, what we can do to protect etc! In short, who should be worried, a common Windows user, a *nix system admin or everyone who uses intel chips..
- saagarjha 7y agoThis vulnerability targets SGX enclaves (although I believe it would affect all memory loads?), which run code that is meant to be isolated from the rest of your computer and is probably currently only being used by DRM on your computer. This is a flaw in your processor and at the moment you probably cannot do anything to protect against this, although work is being done to come up with mitigations. Currently, it seems like they’ll be the kind that’ll slow down your computer.
- redrabbyte 7y agoit affects all loads, but for sgx the attacker scenario is that you have compromised the OS, which makes it significantly easier to create the conditions (faults/microcode assists) that cause the LVI than if you were just another userspace program (but it's not impossible there either)
- saagarjha 7y agoThough I don't have much knowledge of this area, I'm waiting for someone to make a PoC exploiting this from JavaScript ;)
- redrabbyte 7y agonot really / update / no, unless you rely on sgx to protect high value data
- Lind5 7y agoGood background info:New Security Risks Create Need For Stealthy Chips https://semiengineering.com/new-security-risks-create-need-for-stealthier-chips/ https://semiengineering.com/new-security-risks-create-need-f... Determining What Really Needs To Be Secured In A Chip https://semiengineering.com/determining-what-really-needs-to-be-secured-in-a-chip/ https://semiengineering.com/determining-what-really-needs-to...
- nneonneo 7y agoThere was a CTF this weekend (UTCTF) featuring a task to exploit a program running in a secure SGX enclave. As part of solving that task I spent some time looking into the design of SGX, and I gotta say it doesn’t sound promising. 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.
- warkdarrior 7y ago> I am not surprised at all that SGX wound up being vulnerable to a low-level CPU attack. 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.
- ngneer 7y agoWhat is correctly? You have to understand that SGX was built on an existing infrastructure, without rebuilding the chip. Intel architects ignored side channels for years. So the security specification was being met, except it had ignored a crucial threat. Small comfort. My point is that "correctly" for security can only be defined in the context of a threat model. If the model is incomplete, then you are exposed. I am not aware of a complete threat model for TEE design. And the reason is clear. The threats develop over time, springing into existence as an emergent property of complex designs rewarded by a market that is not keen on incentivizing secure design.
- baybal2 7y agoQuite sensational. 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.
- jokoon 7y agoYes I just don't understand, most big vulnerabilities that make the headlines, even if they involves a lot of people, the vuln scenario looks it's still crumbs. 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.
- saagarjha 7y agoI mean, this vulnerability doesn't seem to be exclusive to SGX. The technique described appears to apply to any sort of normally-inaccessible memory.
- MauranKilom 7y agoI understand how they turn incorrect store forwarding into an attack, but can somebody summarize what causes the store forwarding to be wrong in the first place?
- redrabbyte 7y agoshort version: only the lower bits of an address are compared at first, because the rest might take a while to resolve so the cpu can speculate that the rest is gonna match as well and start to work with the data, and then either keep it or throw it away once the rest of the address is known
- driverdan 7y agoAn 11 month embargo for a widespread security flaw like this is unacceptable. Researchers need to refuse to comply with this. 90 days by default and an extra 90 on request is more than enough. If they can't get their shit together in six months they won't be able to in 12.
- 3pt14159 7y agoWe need an industry standard shut-up-and-pay-me system. First 90 days free. Then some sort of quadratic formula for every month after that.
- yjftsjthsd-h 7y agoI'd prefer 90 days and then unconditional publishing. I grant that making companies' desire for silence actually affect the bottom line has appeal, but 1. some companies have deep pockets, and 2. I'm not ethically comfortable with anything of the form "pay me to not disclose this bad thing".
- roca 7y agoThe headline and a lot of the writeup is very confusing. This attack does not let you modify architectural state, only speculative state. The headlines sound like you can corrupt the values that the program actually ends up using, but you can't. You can only modify speculative state and use those changes to get more control over what data is leaked through side channels.
- gjsman-1000 7y agoI'm not a technical expert, but check out the guy who made the fake movie trailer's channel. He has written parody songs for almost all of the Intel execution attacks there are, which is quite hilarious.
- redrabbyte 7y agohe happens to be an author/co-author of all of those papers ;)
- kumarski 7y agoefabless becomes more and more relevant every day.
- aSplash0fDerp 7y agoWould buffered connectivity mitigate what is becoming a Swiss cheese infrastructure of hardware (security holes in everything)? 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.
- saagarjha 7y agoWhat is buffered connectivity?
- aSplash0fDerp 7y agoHonestly, I think they need to create new categories for the protocols used for the traditional Internet and divide it into Local Area Protocals (LAPs) and Wide Area Protocols (TCP/IP is the defacto WAP) as well as adding a gateway (like AppleTalk to IP gateways of yore) so that there is more than an airgap (its a different language/protocol as well) separating your network from from the worlds biggest venerable network. 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.
- saagarjha 7y agoHow would that help with this issue, which is specific to the processor itself?
- aSplash0fDerp 7y agoReally??? 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.
- userbinator 7y agoThis is a good thing when the secure enclave is user-hostile and the attacker is the user. 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.
- sterlind 7y agoCloud providers already offer full blades, though they're quite expensive. I could imagine vendors commissioning custom hardware that electrically isolates CPU cores and caches, like a sort of hyper MMU. The challenge lies in combining these "nodelets" together dynamically to make larger VM skus when needed without compromising security when they're supposed to be isolated. Plus you'd have to design a ton of new hardware which isn't cheap. 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.)
- saagarjha 7y ago> attempting to isolate trusted and untrusted code on the same hardware is ultimately futile I hope you don't like browsing the web…
- strstr 7y agoIntel continues to get beaten up by their decision to defer access checks in speculation. Meltdown, L1TF, and now LVI-stale-data are all rooted in one mistake. Fortunately, the silicon fix for Meltdown appears to mitigate these issues ("RDCL_NO"). But it also introduces LVI-NULL (which is admittedly more restricted, but still problematic). 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/insights/deep-dive-load-value-injection#injectnonzerodata https://software.intel.com/security-software-guidance/insigh... [1] https://lviattack.eu/lvi.pdf https://lviattack.eu/lvi.pdf [2] https://software.intel.com/security-software-guidance/insights/processors-affected-load-value-injection https://software.intel.com/security-software-guidance/insigh...
- zerkten 7y agoThis is a bit of a naive question, but do the Ice Lake mitigations address any of the performance impact from the software updates that address earlier issues?
- strstr 7y agoDepending on your risk tolerance, mostly yes: 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.