24 ms·
Branch Privilege Injection: Exploiting branch predictor race conditions
See also: ETH Zurich researchers discover new security vulnerability in Intel processors - https://ethz.ch/en/news-and-events/eth-news/news/2025/05/eth-zurich-researchers-discover-new-security-vulnerability-in-intel-processors.html https://ethz.ch/en/news-and-events/eth-news/news/2025/05/eth...
- progval 1y agoResearchers' blog post: https://comsec.ethz.ch/research/microarch/branch-privilege-injection/ https://comsec.ethz.ch/research/microarch/branch-privilege-i... Paper: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
- ncr100 1y agoImpact illustration: > [...] the contents of the entire memory to be read over time, explains Rüegge. “We can trigger the error repeatedly and achieve a readout speed of over 5000 bytes per second.” In the event of an attack, therefore, it is only a matter of time before the information in the entire CPU memory falls into the wrong hands.
- formerly_proven 1y agoPrepare for another dive maneuver in the benchmarks department I guess.
- cenamus 1y agoAnd if not, why did they introduce severe bugs for a tiny performance improvement?
- bloppe 1y agoIt's not tiny. Speculative execution usually makes code run 10-50% faster, depending on how many branches there are
- bee_rider 1y agoYeah… folks who think this is just some easy to avoid thing should go look around and find the processor without branch prediction that they want to use. On the bright side, they will get to enjoy a much better music scene, because they’ll be visiting the 90’s.
- wbl 1y agoIBM Stretch had branch prediction. Pentium in the early 1990s had it. It's a huge win with any pipelining.
- yencabulator 1y ago> Does Branch Privilege Injection affect non-Intel CPUs? > No. Our analysis has not found any issues on the evaluated AMD and ARM systems.
- titzer 1y agoThat's a vast underestimate. Putting in lfence before every branch is on the order of 10X slowdown.
- grumbelbart2 1y agoThere is of course a slight chicken-egg-thing here: If there was no (dynamic) branch prediction, we (as in compilers) would emit different code that is faster for non-predicting CPUs (and presumably slower for predicting CPUs). That would mitigate a bit of that 10x.
- anyfoo 1y agoA bit. I think we've shown time and time again that letting the compiler do what the CPU is doing doesn't work out, most recently with Itanium.
- School-Cotton 1y agoA modern processor pipeline is dozens of cycles deep. Without branch prediction, we would need to know the next instruction at all times before beginning to fetch it. So we couldn’t begin fetching anything until the current instruction is decoded and we know it’s not a branch or jump. Even more seriously, if it is a branch, we would need to stall the pipeline and not do anything until the instruction finishes executing and we know whether it’s taken or not (possibly dozens of cycles later, or hundreds if it depends on a memory access). Stalling for so many cycles on every branch is totally incompatible with any kind of modern performance. If you want a processor that works this way, buy a microcontroller.
- superblas 1y ago> If you want a processor that works this way, buy a microcontroller. The ARM Cortex-R5F and Cortex-M7, to name a few, have branch predictors as well, for what it’s worth ;)
- jeffbee 1y agoYou can still have a static branch predictor. That has surprisingly good coverage. I'm not saying this is a great idea, just pointing it out.
- tremon 1y agoBut branch prediction doesn't necessarily need complicated logic. If I remember correctly (it's been 20 years since I read any papers on it), the simple heuristic "all relative branches backwards are taken, but forward and absolute branches are not" could achieve 70-80% performance of the state-of-the-art implementations back then.
- anyfoo 1y agoDo you mean overall or localized to branch prediction? Assuming all of that is true, you're talking about a 20-30% performance hit?
- tsukikage 1y agoWe need software and hardware to cooperate on this. Specifically, threads from different security contexts shouldn't get assigned to the same core. If we guarantee this, the fences/flushes/other clearing of shared state can be limited to kernel calls and process lifetime events, leaving all the benefits of caching and speculative execution on the table for things actually doing heavy lifting without worrying about side channel leaks.
- tankenmate 1y agoI get you, but devs struggle to configure nginx to serve their overflowing cauldrons of 3rd party npm modules of witches incantations. Getting them securely design and develop security labelled cgroup based micro (nano?) compute services for inferencing text of various security levels is beyond even 95% of coders. I'd posit that it would be a herculean effort even for 1% devs. Just fix the processors?
- tsukikage 1y agoIt's not a "just" if the fix cripples performance; it's a tradeoff. It is forced to hurt everything everywhere because the processor alone has no mechanism to determine when the mitigation is actually required and when it is not. It is 2025 and security is part of our world; we need to bake it right into how we think about processor/software interaction instead of attempting to bolt it on after the fact. We learned that lesson for internet facing software decades ago. It's about time we learned it here as well.
- tankenmate 1y agoIs the juice worth the squeeze? Not everything needs Orange Book (DoD 5200.28-STD) Class B1 systems.
- deleted 1y ago[deleted]
- immibis 1y ago
- trebligdivad 1y agoThanks! It would be great if someone could update the title URL to that blog post; the press release is worse than useless.
- dang 1y agoOk, we've changed to that from https://ethz.ch/en/news-and-events/eth-news/news/2025/05/eth-zurich-researchers-discover-new-security-vulnerability-in-intel-processors.html https://ethz.ch/en/news-and-events/eth-news/news/2025/05/eth... above.
- trebligdivad 1y agoThanks!
- alberto-m 1y agoI don't know guys. Yes, the direct link saves a click, but the original title was more informative for the casual reader. I'm not a professional karma farmer and in dang's shoes I would have made the same adjustment, but I can't deny that seeing the upvote rate going down by 75% after the change was a little harsh.
- dang 1y agoIt was on the frontpage for 23 hours (and still is!) so the submission still did unusually well. I thought about adding the blog post link to the top text (a bit like in this thread: https://news.ycombinator.com/item?id=43936992 https://news.ycombinator.com/item?id=43936992), but https://news.ycombinator.com/item?id=43974971 https://news.ycombinator.com/item?id=43974971 was the top comment for most of the day, and that seemed sufficient. Edit: might as well belatedly do that!
- tmtvl 1y agoThanks for all your hard work as always, dang.
- dang 1y agoThanks! We've changed the URL above from the university press release (https://ethz.ch/en/news-and-events/eth-news/news/2025/05/eth-zurich-researchers-discover-new-security-vulnerability-in-intel-processors.html https://ethz.ch/en/news-and-events/eth-news/news/2025/05/eth...) to that first link.
- mettamage 1y agoGood to see Kaveh Razavi, he used to teach at my uni in the Vrije Universiteit in Amsterdam :) The course Hardware Security was crazy cool and delved into stuff lijke this.
- markus_zhang 1y agoI checked out this course (and another one from Vrije about malware) a couple of years ago, back then there was very little public info about the courses. Do you know if there is any official recording or notes online? Thanks in advance.
- thijsr 1y agoAs far as I am aware, the course material is not public. Practical assignments are an integral part of the courses given by the VUSEC group, and unfortunately those are difficult to do remotely without the course infrastructure. The Binary and Malware Analysis course that you mentioned builds on top of the book "Practical Binary Analysis" by Dennis Andriesse, so you could grab a copy of that if you are interested.
- mettamage 1y agoAh yea, he gave a guest lecture on how he hacked a botnet! More info here: https://krebsonsecurity.com/2014/06/operation-tovar-targets-gameover-zeus-botnet-cryptolocker-scourge/ https://krebsonsecurity.com/2014/06/operation-tovar-targets-... it's been a while back :)
- markus_zhang 1y agoThanks. I understand that it is difficult to do it remotely. I do have the book! I bought it a while ago but did not have the pleasure to check it out.
- mettamage 1y agoNo, but last time I checked you can be a contracted student for 1200 euro's. If I knew what I was getting into at the time, I'd do it. I did pay for extra, but in my case it was the low Dutch rate, so for me it was 400 euro's to follow hardware security, since I already graduated. But I can give a rough outline of what they taught. It has been years ago but here you go. Hardware security: * Flush/Reload * Cache eviction * Spectre * Rowhammer * Implement research paper * Read all kinds of research papers of our choosing (just use VUSEC as your seed and you'll be good to go) Binary & Malware Analysis: * Using IDA Pro to find the exact assembly line where the unpacker software we had to analyze unpacked its software fully into memory. Also we had to disable GDB debug protections. Something to do with ptrace and nopping some instructions out, if I recall correctly (look, I only low level programmed in my security courses and it was years ago - I'm a bit flabbergasted I remember the rough course outlines relatively well). * Being able to dump the unpacked binary program from memory onto disk. Understanding page alignment was rough. Because even if you got it, there were a few gotcha's. I've looked at so many hexdumps it was insane. * Taint analysis: watching user input "taint" other variables * Instrumenting a binary with Intel PIN * Cracking some program with Triton. I think Triton helped to instrument your binary with the help of Intel PIN by putting certain things (like xor's) into an SMT equation or something and you had this SMT/Z3 solver thingy and then you cracked it. I don't remember got a 6 out of 10 for this assignment, had a hard time cracking the real thing. Computer & Network Security: * Web securtiy: think XSS, CSRF, SQLi and reflected SQLi * Application security: see binary and malware analysis * Network security: we had to create our own packet sniffer and we enacted a Kevin Mitnick attack (it's an old school one) where we had to spoof our IP addresses, figure out the algorithm to create TCP packet numbers - all in the blind without feedback. Kevin in '97 I believe attacked the San Diego super computer (might be wrong about the details here). He noticed that the super computer S trusted a specific computer T. So the assignment was to spoof the address of T and pretend we were sending packets from that location. I think... writing this packet sniffer was my first C program. My prof. thought I was crazy that this was my first time writing C. I was, I also had 80 hours of time and motivation per week. So that helped. * Finding vulnerabilities in C programs. I remember: stack overflows, heap overflows and format strings bugs. ----- For binary & malware analsys + computer & network security I highly recommend hackthebox.eu For hardware security, I haven't seen an alternative. To be fair, I'm not looking. I like to dive deep into security for a few months out of the year and then I can't stand it for a while.
- arghwhat 1y ago> On an up to date Ubuntu 24.04 So not very up to date, but I suppose mitigations haven't changed significantly upstream since then.
- necubi 1y ago24.04 is the most recent LTS (long term support) release; it's what users are meant to be running for anything important
- FirmwareBurner 1y ago[flagged]
- arghwhat 1y agoMy point is that it is not representative of the current state of the kernel. The kernel has nothing to do with Ubuntu, its release schedule and LTS's. Distro LTS releases also often mean custom kernels, backports, hardware enablement, whatnot, which makes it a fork, so unless were analyzing Ubuntu security rather than Linux security, mainline should be used.
- BoredPositron 1y agoMicrocode updates have nothing to do with the kernel?
- blueflow 1y ago
- rtkwe 1y agoI wonder if there's similar gaps in AMD hardware? Seems like speculative execution is simply an extremely hard to patch vulnerability in a share processor space so I wonder how AMD has avoided it.
- tmoertel 1y agoAccording to the authors' blog post: > Does Branch Privilege Injection affect non-Intel CPUs? > No. Our analysis has not found any issues on the evaluated AMD and ARM systems. Source: https://comsec.ethz.ch/research/microarch/branch-privilege-injection/ https://comsec.ethz.ch/research/microarch/branch-privilege-i...
- __turbobrew__ 1y agoIntel is getting kicked while it is down.
- pdpi 1y agoThe short of it is that AMD haven’t “avoided it”. Speculative execution side channels aren’t one vulnerability but rather a whole family of vulnerabilities. This particular one is (apparently) Intel-only, same as Meltdown was, but AMD was also vulnerable to the original Spectre.
- bee_rider 1y agoPedantically, speculative execution isn’t the vulnerability, it is a necessary mechanism for every high-performance CPU nowadays (where “nowadays” started, like, around the turn of the century). However, bugs and vulnerabilities in speculative execution engines are very widespread because they are complicated. There are probably similar bugs in AMD and ARM, I mean how long did these bugs sit undiscovered in Intel, right? Unfortunately the only real fix is to recognize that you can’t isolate code running on a modern system, which would be devastating to some really rich companies’ business models.
- fc417fc802 1y ago> the only real fix is to recognize that you can’t isolate code running on a modern system Does pinning VMs to hardware cores (including any SMT'd multiples) fix this particular instance? My understanding was that doing that addressed many of the modern side channel exploits. Of course that's not ideal, but it's not too bad in an era where the core count of high end CPUs continues to creep upwards.
- whatever1 1y agoIt’s dead, can you please stop stubbing it?
- anonymars 1y agoI thought I understand these words, yet I don't understand what you mean
- margorczynski 1y agoI wonder if there's any way to recover for Intel. They don't have anything worthwhile on the market, R&D takes a lot of time and their foundries are a constant source of losses as they're inferior compared to the competition. On top of that x86 seems to be pushed out more and more by ARM hardware and now increasingly RISC-V from China. But of course there's the US chip angle - will the US, especially after the problems during Covid, let a key manufacturer like Intel bite the dust?
- emkoemko 1y agodidn't i read something about apple,nvidia and other companies looking to use their foundries? why would they do that if its inferior or was that something else?
- greenavocado 1y agoBecause there's nothing else in America
- layer8 1y agoIntel still has well over 70% x86 market share. They have a long runway. Arm had only 15% datacenter market share last year, and still hasn’t made much headway in the Windows market.
- freeone3000 1y agoArm is making huge gains though — five years ago they had less than 5%. The future of x86 is not bright.
- baq 1y agox86 vs arm doesn’t matter. Hardware matters. Intel needs to make the best cpu again. It can be x86, it can be arm, it can be risc-v.
- 1y ago
- rini17 1y agoIf CPU brach predictor had bits of information readily available to check buffer boundaries and privilege level of the code, all this would be much easier to prevent. But apparently that will only happen when we pry out the void* from the cold C programmers' hands and start enriching our pointers with vital information.
- ajross 1y agoI don't see how you think that will help? It's not about software abstraction, it's about hardware. Changing the "pointer" does nothing to the transistors. Doing what you want would essentially require a hardware architecture where every load/store has to go through some kind of "augmented address" that stores boundary information. Which is to say, you're asking for 80286 segmentation. We had that, it didn't do what you wanted. And the reason is that those segment descriptors need to be loaded by software that doesn't mess things up. And it doesn't, it's "just a pointer" to software and amenable to the same mistakes.
- nottorp 1y agoI suppose a CPU that only runs Rust p-code is what the OP is dreaming about...
- ajross 1y agoGenerated rust "p-code" would presumably be isomorphic to LLVM IR, which doesn't have this behavior either and would be subject to the same exploits. Again, it's just not a software problem. In the real world we have hardware that exposes "memory" to running instructions as a linear array of numbers with sequential addresses. As long as that's how it works, you can demand an out of bounds address (because the "bounds" are a semantic thing and not a hardware thing). It is possible to change that basic design principle (again, x86 segmentation being a good example), but it's a whole lot more involved than just "Rust Will Fix All The Things".
- nottorp 1y ago
- layer8 1y agoIntel security advisory: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01247.html https://www.intel.com/content/www/us/en/security-center/advi...
- unit149 1y ago[dead]
- j45 1y agoSince the cloud is someone else's computer, and someone else's shared CPU, is cloud hosting (including vps) potentially impacted? Look forward to learning how this can be meaningfully mitigated.
- andrewla 1y agoIntel claims [1] that they already have microcode mitigation. Like Spectre and Meltdown this is likely to have performance implications. [1] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01247.html https://www.intel.com/content/www/us/en/security-center/advi...
- j45 1y agoSpectre and Meltdown had some pretty big performance hits in the beginning. Wonder how much it will differ here in real world, third party (and independent) testing.
- matja 1y agoFor reads across different VMs on the same CPU, theoretically TME-MK could mitigate the usefulness of the memory reads by having each VM access memory using a different memory encryption key, but I don't know of any hypervisors that implement this. AMD has had SEV support in QEMU for a long time, which some cloud hosting providers use already, that would mitigate any such issue if it occurred on AMD EPYC processors.
- wahern 1y agoMemory encryption doesn't usually protect against these kinds of side channels. You're not reading memory directly, but inferring it based on discernible behavior of the privileged code. Inasmuch as SEV and TME-MK are marketed as protecting VM guest memory from host machine snooping, they've proven insufficient many times before.[1] In the end, you have to trust your VM hosting provider, and trust that they've written their hypervisors in a robust way that takes into account these unforeseen (yet predictable) issues when isolating guests from each other. [1] See, e.g., https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3010.html https://www.amd.com/en/resources/product-security/bulletin/a... and https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/mktme-side-channel-impact-on-intel-tdx.html https://www.intel.com/content/www/us/en/developer/articles/t...
- yonatan8070 1y agoJust to make sure I got this right, at this point in time there are patches out for all major operating systems that can mitigate this/apply relevant microcode to mitigate it?
- dboreham 1y agoYes. Embargo date May 13 (today).
- tannhaeuser 1y ago> All intel processors since the 9th generation (Coffee Lake Refresh) are affected by Branch Privilege Injection. However, we have observed predictions bypassing the Indirect Branch Prediction Barrier (IBPB) on processors as far back as 7th generation (Kaby Lake). From that piece of text on the blog, I don‘t quite unterstand if Kaby Lake CPUs are affected or not.
- chrisweekly 1y agoI interpret it as including Kaby Lake.
- autoexec 1y agowhich would mean that all our intel machines have been vulnerable and defenseless for the last 9 years.
- fwip 1y agoAt least some Kaby Lake CPUs are affected, but they can't say for sure that all of them are.
- lostmsu 1y agoNo, I think they are saying that they can only demonstrate exploit on Coffee Lake Refresh and later, but the issue that let them create exploit exists all the way back to Kaby Lake. So they are also probably exploitable, but this specific exploit does not target them.
- smartmic 1y ago> Closing these sorts of gaps requires a special update to the processor’s microcode. This can be done via a BIOS or operating system update and should therefore be installed on our PCs in one of the latest cumulative updates from Windows. Why mention only Windows, what about Linux users?
- matja 1y agoThe Linux kernel has had microcode loading support (`CONFIG_MICROCODE` / `CONFIG_MICROCODE_INTEL`) but many years, but it does require that Intel release the microcode files necessary for distribution maintainers to update the packages, then it should be included in a system update.
- ajross 1y agoIntel distributes microcode updates for Linux here: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... , and the distro are all set up to pull from there and distribute automatically. Not expert enough to know what to look for to see if these particular mitigations are present yet.
- brokenmachine 1y agoOn an Ubuntu 24.04.2 machine: dpkg -l | grep microcode ii amd64-microcode 3.20231019.1ubuntu2.1 amd64 Processor microcode firmware for AMD CPUs ii intel-microcode 3.20250211.0ubuntu0.24.04.1 amd64 Processor microcode firmware for Intel CPUs ii iucode-tool 2.3.1-3build1 amd64 Intel processor microcode tool
- yencabulator 1y agoResearchers say this is CVE-2024-45332. INTEL-SA-01247 covers that CVE. Microcode release 20250512 has that INTEL-SA mitigated. https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-20250512 https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01247.html https://www.intel.com/content/www/us/en/security-center/advi...
- dzdt 1y agoThe end-user processor slowdowns from Spectre and Meltdown mitigations were fairly substantial. Has anyone seen an estimate of how much the microcode updates for this new speculative vulnerability are going to cost in terms of slowdown?
- leonidasv 1y ago> Our performance evaluation shows up to 2.7% overhead for the microcode mitigation on Alder Lake. We have also evaluated several potential alternative mitigation strategies in software with overheads between 1.6% (Coffee Lake Refresh) and 8.3% (Rocket lake) https://comsec.ethz.ch/research/microarch/branch-privilege-injection/ https://comsec.ethz.ch/research/microarch/branch-privilege-i...
- dzdt 1y agoThanks, missed that! I remember seeing benchmarks showing like 15% slowdown from Spectre/Meltdown mitigations, so this is not as bad as that, but that is on top of the other too I guess...
- HeliumHydride 1y agohttps://scholar.harvard.edu/files/mickens/files/theslowwinter.pdf https://scholar.harvard.edu/files/mickens/files/theslowwinte... "Unfortunately for John, the branches made a pact with Satan and quantum mechanics [...] In exchange for their last remaining bits of entropy, the branches cast evil spells on future generations of processors. Those evil spells had names like “scaling-induced voltage leaks” and “increasing levels of waste heat” [...] the branches, those vanquished foes from long ago, would have the last laugh."
- Hackbraten 1y agoI love James Mickens! https://www.usenix.org/system/files/1401_08-12_mickens.pdf https://www.usenix.org/system/files/1401_08-12_mickens.pdf > The Mossad is not intimidated by the fact that you employ https:// https://. If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, […] they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them.
- wood_spirit 1y agoSo this is where they got the pager and walkie talkie ideas from
- genewitch 1y agoYou know, I didn't really think of this till your comment: this was a vast conspiracy spanning years. You always hear, when discussions of "conspiracies" happen, things like "it would involve too many people, too many moving parts" like opsec would be impossible. And then you have the pagers. Kinda like the old chestnut that rich people are only rich on paper and then, Musk buys twitter. Not tesla, or some DBA, Musk. This decade might actually be the season of reveal.
- angra_mainyu 1y ago
- 201984 1y agomitigations=off Don't care.
- matja 1y ago"Don't mind me running this piece of WASM in a webworker to collect all the useful encryption keys and cookies in your RAM..."
- johnnyjeans 1y agoUncaught ReferenceError: WebAssembly is not defined
- vlovich123 1y agoYou don't need WASM to deploy Spectre/Meltdown. Vanilla JS works just fine which is what was demonstrated in the original paper.
- deleted 1y ago[deleted]
- brobinson 1y agoDidn't all the major browsers alter their timing APIs to make this impossible/difficult?
- anyfoo 1y agoI'm not an expert, but I think you can only make this harder by intentionally making timers less precise (even adding some random fuzz). Someone may correct me if I'm wrong, but I think statistically, a less precise timer means you will just need a longer runtime. Suppose you want to measure the distribution of the delay between recurring events (which is basically what's at the heart of those vulnerabilities). Suppose the delays are all sub-milliseconds, and that your timer, to pick something ridiculous, only has a 2 second granularity. You may at first think that you cannot measure the sub-millisecond distribution with such a corse timer. But consider that event and timers are not synchronized to each other, so with enough patience, you will still catch some events barely on the left or on the right side of your 2 second timer tick. Do this over a long enough time, and you can reconstruct the original distribution. Even adding some randomness to the timer tick just means you need more samples to suss the statistic out. Again, I am not an expert, and I don't know if this actually works, but that's what I came up with intuitively, and it matches with what I heard from some trustworthy people on the subject, namely that non-precision timers are not a panacea.
- rakingleaves 1y agoAnyone know how this relates to the Training Solo attack that was just disclosed? https://www.vusec.net/projects/training-solo/ https://www.vusec.net/projects/training-solo/
- hashstring 1y agoBoth exploit Spectre V2, but in different ways. My takeaway: Training Solo: - Enter the kernel (and switch privilege level) and “self train” to mispredict branches to a disclosure gadget, leak memory. Branch predictor race conditions: - Enter the kernel while your trained branch predictor updates are still in flight, causing the updates to be associated with the wrong privilege level. Again, use this to redirect a branch in the kernel to a disclosure gadget, leak memory.
- gitroom 1y agoyeah this just makes me wanna see real world numbers on the slowdown, cuz honestly all these microcode fixes feel like trading off years of speed for maybe a little more peace of mind - you ever think well actually move off this cycle or is it just here to stay?
- myself248 1y agoI'd love to see a graph showing mitigations=off vs mitigations=on speed gains over the years. It feels like most of the new tricks have had vulnerabilities of some sort, which eat up some or most of their gains. Of course at launch, the vulns haven't been found yet, so the performance uplift claims are all fluff based on the reckless actions of an unprotected trick. By the time the skeletons have come out of the closet, the release hype cycle is far in the past, and only a few nerd blogs will cover the corresponding performance hit. Lather, rinse, repeat for the next launch. New tricks, new reckless performance gains, big uplift numbers, hope it takes a little while before anybody points out the holes in the emperor's clothes. But at the end of the day, the actual performance progress over time is, I suspect, dramatically slower than what the naïve summation of individual launch-day claims would suggest. To your second point: I think it's here to stay as long as we allow someone else's code (via js, webassembly, and their ilk) to run on our processors as a matter of course. A rethink of the entire modern web, back to a simpler markup language that isn't Turing-complete and can't leak data back to the attacker's server, would be needed before we could turn the mitigations off and enjoy the performance we were promised. But of course, if we get rid of the modern web as we know it, we probably don't need all that performance anyway. An old BlueWave/QWK mailer consumes 10,000x less resources than a Gmail tab, you know?
- The28thDuck 1y agoHaven’t we been here before? It seems like it’s very similar to the branch prediction exploits of the late 2010s. Is there something particularly novel about this class of exploits?
- mettamage 1y agoProbably, I haven't had time to delve into the article yet. But ever I first learned about them I got the hunch that they'd never fully go away. Then people say "no that's not possible, we got security in place." So then the researchers showcase a new demo where they use their existing knowledge with the same issue (i.e. scaling-induced voltage leaks). I suspect this will go on and on for decades to come.
- dboreham 1y agoIt's the same exploit, just exploiting a bug in the mitigation for the first exploit.
- LkpPo 1y agoPredictable suite.^_^ Disable the feature in BIOS if possible. Branch prediction is a rotten plank that needs to be scrapped. It's a remarkably bad idea that doesn't deserve to be saved.
- eigenform 1y agoGreat read! Some boiled-down takeaways: - Predictor updates may be deferred until sometime after a branch retires. Makes sense, otherwise I guess you'd expect that branches would take longer to retire! - Dispatch-serializing instructions don't stall the pipeline for pending updates to predictor state. Also makes sense, considering you've already made a distinction between "committing the result of the branch instruction" and "committing the result of the prediction". - Privilege-changing instructions don't stall the pipeline for pending updates either. Also makes sense, but only if you can guarantee that the privilege level is consistent between making/committing a prediction. Otherwise, you might be creating a situation where predictions generated by code in one privilege level may be committed to state used in a different one? Maybe this is hard because "current privilege level" is not a single unambiguous thing in the pipeline?
- Alcatros552 1y agoAs it seems a lot of people are not aware that this one is a newer generation of branch predictor issue. You can see that Intels eIBRS doesn't mitigate the problems and make them susceptible to attacks. To prevent bigger issues the issue was released after Intel has been informed of the Issue and most systems are patched in the meantime.
- pawanjswal 1y agoJust when we thought Spectre was fading, it pulls a full sequel—Intel CPUs still keeping things spicy!
- arkh 1y agoSo is it time for some cryptography coprocessor / cards?
- x3al 1y agoIs there an easy way to run a browser on some phone/tablet and everything else on a desktop just to isolate the web and JS from accessing your desktop?