10 ms·
Reptar
- Flow 3y agoWould be possible to describe a modern CPU in something like TLA+ to find all non-electrical problems like these?
- boxfire 3y agoThere are still bit flipping tricks like rowhammer for RAM, I wouldn't be surprised if there are such vulnerabilities in some CPUs.
- sterlind 3y agoRowhammer is an electrical vulnerability though. PP specified non-electrical vulns.
- sterlind 3y agoI've heard Intel does use TLA+ extensively for specifying their designs and verifying their specs. But TLA+ specs are extremely high-level, so they don't capture implementation details that can lead to bugs. And model checking isn't a formal proof, only (tractably small) finite state spaces can be checked with TLC. And even there, you're only checking the invariants you specified. That said, I'm sure there's some verification framework like SPARK for VHDL, and this feels like exactly the kind of thing it should catch.
- dboreham 3y agoFormal methods have been used in CPU design for nearly 40 years [1] but not yet for everything, and the methods tend to not have "round-trip-engineering" properties (e.g. TLA+ is not actually proving validity of the code you will run in production, just your description of its behavior and your idea of exhaustive test cases). [1] https://www.academia.edu/60937699/The_IMS_T_800_Transputer https://www.academia.edu/60937699/The_IMS_T_800_Transputer
- foobiekr 3y agoCPU designers are so professional about verification and specification that they _dwarf_ software. There's just no comparison.
- saagarjha 3y agoSee also Intel’s advisory, which has a description of impact: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00950.html https://www.intel.com/content/www/us/en/security-center/advi... > Sequence of processor instructions leads to unexpected behavior for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege and/or information disclosure and/or denial of service via local access.
- yborg 3y ago'Some' appears to be almost any Intel x86 CPU made in the last 6 years.
- tedunangst 3y agoTheir diagnosis reminds me of what happened when qemu ran into repz ret. https://repzret.org/p/repzret/ https://repzret.org/p/repzret/
- Lammy 3y ago> the processor would begin to report machine check exceptions and halt. I get it https://www.youtube.com/watch?v=dXekDCcw2FE https://www.youtube.com/watch?v=dXekDCcw2FE
- shadowgovt 3y ago... it literally took me all Goddamn day. Well done. Credit where credit is due: Google has some of the best codenames.
- deleted 3y ago[deleted]
- doublerabbit 3y agoAny reason to why its named after the dinosaur from the cartoon Rugrats? Or was that what was on TV at the time? Maybe I should start hacking while watching Teenage Mutant Ninja Turtles.
- 2OEH8eoCRo0 3y agorep is an assembly instruction prefix
- Blackthorn 3y agoI think from the memey line "Halt! I am Reptar!" Plus the rep prefix
- AdmiralAsshat 3y agoIf you discover a major processor vulnerability and wanna name it Shredder/Krang/Bebop/Rocksteady, I feel like you will have earned that right!
- xyst 3y agoReading this makes me realize how little I know of the hardware that runs my software > Prefixes allow you to change how instructions behave by enabling or disabling features Why do we need “prefixes” to disable or enable features? Is this for dynamically toggling feature so you don’t have to go into BIOS?
- jeffbee 3y agoIt's just because x86 as an ISA has accreted over the course of 40+ years, and has variable-length instructions. Every time they extend the ISA they carve out part of the opcode space to squeeze in a new prefix. This will only continue, considering that Intel has proposed another new scheme this year.
- shenberg 3y agoPrefixes are modifiers to specific instructions executed by the processor, e.g. to control the size of the operands or enable locking for concurrency.
- Tuna-Fish 3y agox86 was designed in 78, basically for the purpose of running a primitive laser printer (or other similar workloads). The big problem with this is that the encoding space for instructions was "efficiently utilized". When new instructions, or worse, additional registers were later added, you had to fit the new instruction variants in somehow, and you did this by tacking on prefixes.
- mschuster91 3y agoNah, x86 goes even earlier in its heritage - it was, effectively, a bolt-on on Intel's way older designs, as a huge part of the 8086 was being ASM source-compatible with the older 8xxx chips, even as the instruction set itself changed [1]. What utterly amazes me is that the original 8086 was mostly designed by hand by a team of not even two dozen people - and today, we got hundreds if not thousands of people working on designing ASICs... [1] https://en.wikipedia.org/wiki/Intel_8086#The_first_x86_design https://en.wikipedia.org/wiki/Intel_8086#The_first_x86_desig...
- rvba 3y agoIt looks like Intel was cutting corners to be faster than AMD and now all those thigs come out. How much slower will all those processors be after multiple errata? 10%? 30%? 50%? In a duopoly market there seems to be no real competition. And yes I know that some (not all) bugs also happen for AMD.
- mschuster91 3y ago> And yes I know that some (not all) bugs also happen for AMD. Some of these novel side-channel attacks actually even apply in completely unrelated architectures such as ARM [1] or RISC-V [2]. I think the problem is not (just) a lack of competition (although you're right that the duopoly in desktop/laptop/non-cloud servers for x86 brings its own serious issues, I've written and ranted more often than I can count [3]), it rather is that modern CPUs and SoCs have simply become so utterly complex and loaded with decades worth of backwards-compatibility baggage that it is impossible for any single human, even a small team of the best experts you can bring together, to fully grasp every tiny bit of them. [1] https://www.zdnet.com/article/arm-cpus-impacted-by-rare-side-channel-attack/ https://www.zdnet.com/article/arm-cpus-impacted-by-rare-side... [2] https://www.sciencedirect.com/science/article/pii/S0045790622007613 https://www.sciencedirect.com/science/article/pii/S004579062... [3] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=mschuster91%20qualcomm&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
- bobim 3y agoSo no saving grace from the ISA… humans just lost ground on CPU design, and I suspect the situation will worsen when AI will enter the picture.
- mschuster91 3y ago> and I suspect the situation will worsen when AI will enter the picture. For now, AI lacks the contextual depth - but an AI that can actually design a CPU from scratch (and not just rehashing prior-art VHDL it has ... learned? somehow), if that happens we'll be at a Cambrian Explosion-style event anyway, and all we can do is stand on the sides, munch popcorn and remember this tiny quote from Star Wars [1]. [1] https://www.youtube.com/watch?v=Xr9s6-tuppI https://www.youtube.com/watch?v=Xr9s6-tuppI
- varispeed 3y agoIt's going to be a pain for cloud and shared hosting. Most likely dedicated resources on demand will be the future. Some companies already offer it.
- kevincox 3y agoGCP and AWS both offer non-shared hardware. If people want the extra isolation they just need to pay for it.
- bobim 3y agoIs it even possible to design a cpu with out-of-order and speculative execution that would have no security issue? Is the future leads to a swarm of disconnected A55 cores each running a single application?
- SmoothBrain12 3y agoYes, but they won't clock as fast because they'll be waiting for RAM.
- bobim 3y agoWe need to keep programs small so they fit in the cache.
- moffkalast 3y agoWe need 2 GBs of L1 cache, thus solving the cache miss problem once and for all.
- rep_lodsb 3y ago640K should be enough for anyone ;)
- Tuna-Fish 3y agoThis vulnerability was not caused by OoO or speculative execution. It was caused by the fact that x86 was designed 45 years ago, and has had feature after feature piled on the same base, which has never been adequately rebuilt. The more proximate cause is that some instructions with multiple redundant prefixes (which is legal, but pointless) have their length miscalculated by some Intel CPUs, which results in wrong outcomes.
- epcoa 3y agoNot entirely pointless, redundant prefixes are occasionally the useful method for alignment.
- tasty_freeze 3y agoBenchmarking is always problematic -- what is a good representative workload? All the same, I'd be curious if the ucode update that plugs this bug has affected CPU performance, eg, it diverts the "fast short rep move" path to just use the "bad for short moves but great for long moves" version.
- akoboldfrying 3y agoIn the article by Tavis O. linked elsewhere in comments, he suggests disabling the FSRM CPU feature only as an expensive workaround to be taken only if the microcode can't be updated for some reason. That suggests to me that he, at least, expects the update to do better.
- ReactiveJelly 3y agoThat would be the conservative thing to do. If there's no limit on microcode updates, if I was Intel, I'd consider doing that first and then speeding it up again later. Based on the 5-second guess that people who update everything regularly will care that we did the right thing for security, and people who hate updates won't be happy anyway, so at least the first update will be secure if they never get the next one. (I think there is a limit on microcode, they seem conservative to release new ones - I don't remember the details)
- kevincox 3y agoIt's a shame that Google didn't publish numbers. They have very good profiling across all of their servers and probably have incredibly high confidence numbers for the real-world impact on this. (Assuming that your world is lots of copying protocol buffers in C++ and Java)
- writeslowly 3y agoI noticed the Intel advisory [1] says the following Intel would like to thank Intel employees:[...] for finding this issue internally. Intel would like to thank Google Employees: [...] for also reporting this issue. [1] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00950.html https://www.intel.com/content/www/us/en/security-center/advi...
- deleted 3y ago[deleted]
- narinxas 3y agoI wonder how much sooner than google did intel employees found this issue
- narinxas 3y agobut what I am really wondering about is how much money (if any) was the vulnerability worth up the moment when google also discovered this?
- ajross 3y agoAs described it's just a CPU crash exploit that requires local binary execution. Getting to a vulnerability would require understanding exactly how the corrupted microcode state works, and that seems extremely difficult outside of Intel. So as described, this isn't a "valuable" bug.
- derefr 3y agoThis assumes that either 1. partners and interested sponsor-state state actors aren't kept abreast Intel's microcode backend architecture, or 2. that there hasn't been at least one leak of this information from one of these partners into the hands of interested APT developers. I wouldn't put strong faith in either of these assumptions.
- 3y ago
- jefc1111 3y agoThis was a lot more fun than the Google puff piece.
- frontalier 3y agoThe date on the article is for tomorrow?
- bitwize 3y agoCereal Killer: Check this out, it's a memo about how they're gonna deal with those oil spills on the 14th. Acid Burn: What oil spills? Lord Nikon: Yo, brain dead, today's the 13th. Cereal Killer: Whoa, this hasn't happened yet!
- quietpain 3y ago...our validation pipeline produced an interesting assertion... What is a validation pipeline?
- ForkMeOnTinder 3y agoIt's described one paragraph earlier. > I’ve written previously about a processor validation technique called Oracle Serialization that we’ve been using. The idea is to generate two forms of the same randomly generated program and verify their final state is identical.
- 1f60c 3y agoSounds like the real story should be that Google solved the halting problem. :-P
- kadoban 3y agoYou're free to solve the halting problem for restricted sets of programs, that doesn't break any rules of the universe. They also could be just discarding any where it runs for longer than X time, or a bunch of other possibilities.
- tgv 3y agoThey might be generating programs that they know will halt. Like: applications with finite loops and such. There are not enough details.
- mgaunard 3y ago[flagged]
- boneitis 3y agoRather, it looks to be: https://en.wikipedia.org/wiki/Instruction_pipelining https://en.wikipedia.org/wiki/Instruction_pipelining From the Zenbleed link in sibling: > I found this bug by fuzzing, big surprise [..] In fact, vendors fuzz their own products extensively - the industry term for it is Post-Silicon Validation. That is, "a pipeline to validate the pipeline".
- bobse 3y ago[dead]
- mike_d 3y agoThe most awesome part: > This bug was independently discovered by multiple research teams within Google, including the silifuzz team and Google Information Security Engineering.
- deleted 3y ago[deleted]
- yodon 3y agoDupe: https://news.ycombinator.com/item?id=38268043 https://news.ycombinator.com/item?id=38268043 (As of this writing, this post has more votes, the other has more comments)
- dang 3y agoWe'll merge that one hither. Please stand by!
- deleted 3y ago[deleted]
- blauditore 3y agoCan someone give a TL;DR for non-CPU experts? All technical articles seem pretty long and/or complex.
- Arnavion 3y agoSome x86 instructions can have prefixes that modify their behavior in a meaningful way. Such a prefix can be applied generally to any instruction, but it's expected to have no effect when applied to an instruction it doesn't make sense with. But it turns out the CPU actually misbehaves in some cases when this is done. Intel released a CPU firmware update to fix it.
- kmeisthax 3y agox86 has a builtin memory copy instruction, provided by the combination of the movsb instruction and a rep prefix byte, that says you want the instruction to run in a loop until it runs out data to copy. This is "rep movsb". This instruction is fairly old, meaning a lot of code still has it, even though there's faster ways to copy memory in x86. Intel added two features to modern x86 chips that detects rep movsb and accelerates it to be as fast as those other ways. However, those features have a bug. You see, because rep is a prefix byte, you can just keep adding more prefix bytes to the instruction (up to a maximum of 16 AFAIK). x86 has other prefix bytes too, such as rex (used to access registers 8-16), vex, evex, etc. The part of the processor that recognizes a rep movsb does NOT account for these other prefix bytes, which makes the processor get confused in ways that are difficult to understand. The processor can start executing garbage, take the wrong branch in if statements, and so on. Most disturbingly, when multiple physical cores are executing these "rep rep rep rep movsb" instructions at the same time, they will start generating machine check exceptions, which can at worst force a physical machine reboot. This is very bad for Google because they rent out compute time to different companies and they all need to be able to share the same machine. They don't want some prankster running these instructions and killing someone else's compute jobs. We call this a "Denial of Service" vulnerability because, while I can't read someone else's computations or change them, I can keep them from completing, which is just as bad.
- BlueTemplar 3y ago
- rep_lodsb 3y agoThe REX prefix is redundant for 'movsb', but not 'movsd'/'movsq' (moving either 32- or 64-bit words, depending on the prefix). That may have something to do with the bug, if there is any shared microcode between those instructions?
- ZoomerCretin 3y agoIntel is a known partner of the NSA. If Intel was intentionally creating backdoors at the behest of the NSA, how would they look different from this vulnerability and the many other discovered vulnerabilities before it?
- thelittleone 3y agoBut so is Google. It would be some very crafty theatrics if it's all coordinated.
- ZoomerCretin 3y agoOnly the people inserting the backdoor or using it would need to be bound by a National Security Letter's gag order. I doubt anyone at Google (including those subject to NSL gag orders) was made aware of this specific vulnerability. # Google’s commitment to collaboration and hardware security ## As Reptar, Zenbleed, and Downfall suggest, computing hardware and processors remain susceptible to these types of vulnerabilities. This trend will only continue as hardware becomes increasingly complex. This is why Google continues to invest heavily in CPU and vulnerability research. Work like this, done in close collaboration with our industry partners, allows us to keep users safe and is critical to finding and mitigating vulnerabilities before they can be exploited. There's a tension between the NSA wanting backdoors and service providers (CPU designers + Cloud hosting) wanting secure platforms. It's possible that by employing CPU and security researchers, Google can tip the scales a bit further in their favor.
- rep_lodsb 3y agoMy guess is that it would be something that could be exploited via JavaScript. And no JIT would emit an instruction like the one that causes this bug.
- gosub100 3y agothe backdoor would just be an encrypted stream of "random" data flowing right out the RNG. there's some maxim of crypto that encrypted data is indistinguishable from random bytes.
- 3y ago
- dang 3y agoRelated: https://cloud.google.com/blog/products/identity-security/google-researchers-discover-reptar-a-new-cpu-vulnerability https://cloud.google.com/blog/products/identity-security/goo... (via https://news.ycombinator.com/item?id=38268043 https://news.ycombinator.com/item?id=38268043, but we merged the comments hither)
- deleted 3y ago[deleted]
- quotemstr 3y agoIf the problem really is that the processor is confused about instruction length, I'm impressed that this problem can be fixed in microcode without a huge performance hit: my intuition (which could be totally wrong) is that computing the length of an instruction would be something synthesized directly to logic gates. Actually, come to think of it, my hunch is that the uOP decoder (presumably in hardware) is actually fine and that the microcoded optimized copy routine is trying to infer things about the uOP stream that just aren't true --- "Oh, this is a rep mov, so of course I need to go backward two uOPs to loop" or something. I expect Intel's CPU team isn't going to divulge the details though. :-)
- ShadowBanThis01 3y agoIs what? Another useless title.
- eigenform 3y agoI wonder which MCEs are being taken when this is triggered?
- malkia 3y agoKonrad Magnusson from Paradox Interactive (Victoria 3) team found something related to that and mimalloc -> https://github.com/microsoft/mimalloc/issues/807 https://github.com/microsoft/mimalloc/issues/807 Not sure if fully related, but possibly.
- saagarjha 3y agoSeems unlikely unless they somehow emitted redundant prefixes
- lights0123 3y agoThe article mentions > This fact is sometimes useful; compilers can use redundant prefixes to pad a single instruction to a desirable alignment boundary. so I imagine that could happen under the right optimization mode.
- ithkuil 3y agoWhy would a compiler prefer a redundant prefix over a nop for alignment?
- Vecr 3y agoIt can be faster (at runtime).
- ithkuil 3y agoso basically you're saying that the cpu frontend missed the opportunity to ignore the 0x90 because it was an actual instruction which would be converted into an actual nop uop? Is this still the case or modern intel CPUs optimize out the nop in the frontend decoder?
- Vecr 3y agoSome compiler writers thought that was the case, if [0] is related to OP. I don't have a "modern" (after 6th gen) Intel CPU to test it on, but note that most programs are compiled for a relatively generic CPU. [0]: https://github.com/microsoft/mimalloc/issues/807 https://github.com/microsoft/mimalloc/issues/807
- farhanhubble 3y agoThis is such an interesting read, right in the league of "Smashing the stack" and "row hammer". As someone with very little knowledge of security I wonder if CPU designers do any kind of formal verification of the microcode architecture?
- saagarjha 3y agoYes.
- asylteltine 3y agoInteresting write up. The submission needs a better and more accurate title though
- atesti 3y agoI don't understand "ERMS" and "FSRM" and there seems to be nothing good on google about it. Are these just CPUID flags that tell you that you can use a rep movsb for maximum performance instead of optimized SSE memcpy implementations? Or is it a special encoding/prefix for rep movsb to make it faster? In case of the later, why would that be necessary? How does one make use of fsrm?
- tommiegannert 3y agoFound this [1], which also links to the Intel Optimization Manual [2]. Seems like ERMS was a cheaper replacement for AVX and FSRM was a better version, for shorter blocks. > Cheapest versions of later processors - Kaby Lake Celeron and Pentium, released in 2017, don't have AVX that could have been used for fast memory copy, but still have the Enhanced REP MOVSB. And some of Intel's mobile and low-power architectures released in 2018 and onwards, which were not based on SkyLake, copy about twice more bytes per CPU cycle with REP MOVSB than previous generations of microarchitectures. > Enhanced REP MOVSB (ERMSB) before the Ice Lake microarchitecture with Fast Short REP MOV (FSRM) was only faster than AVX copy or general-use register copy if the block size is at least 256 bytes. For the blocks below 64 bytes, it was much slower, because there is a high internal startup in ERMSB - about 35 cycles. The FSRM feature intended blocks before 128 bytes also be quick. [1] https://stackoverflow.com/a/43837564 https://stackoverflow.com/a/43837564 [2] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf http://www.intel.com/content/dam/www/public/us/en/documents/...
- ithkuil 3y agoFSRM is just the name of a cpu optimization that affects existing code. Choosing an optimal instruction choice and scheduling can be done statically during compile time or dynamically (via chosing one of several library functions at runtime, or jitting). In order to be able to detect which is the optimal instruction scheduling at runtime you need to know the actual CPU. You could have a table of all cpu models or you could just ask your OS whether the CPU you run on has that optimization implemented. Linux had to be patched so that it can _report_ that a CPU does implement that optimization. https://www.phoronix.com/news/Intel-5.6-FSRM-Memmove https://www.phoronix.com/news/Intel-5.6-FSRM-Memmove
- tommiegannert 3y agoNice find. That indeed sounds terrible for anyone executing external code in what they believe to be sandboxes. Good thing it can be patched (and AFAICT, it seems to be a good fix, rather than a performance-affecting workaround.)
- tazjin 3y agoCan we get a better title for this? "Reptar - new CPU vulnerability" or something. I thought it was some random startup ad until I picked up the name somewhere else.
- weinzierl 3y agoIf it is changed to what you suggested a question mark would be warranted, because it is not yet clear what can be done with this "glitch" (as the article calls it).
- Thorrez 3y agoIntel says >A potential security vulnerability in some Intel® Processors may allow escalation of privilege and/or information disclosure and/or denial of service via local access. https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00950.html https://www.intel.com/content/www/us/en/security-center/advi...
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- Borg3 3y agoUhm.. Why not padding using NOP ? Looks much more safer that slapping around random prefixes.
- deleted 3y ago[deleted]
- muricula 3y agoModern Intel CPUs I am led to believe that issuing nops is actually slower than adding prefixes. I think there is work in the backend updating retired instruction counters and other state which still occurs for nops, but decoding prefixes happens entirely in the front end. When a nop truly is necessary you will see compilers and performance engineers add prefixes to the nop to make it the desired size.
- krylon 3y agoThis is very well written. I know little about assembly programming and Intel's ISA, let alone their microarchitectures, but I could follow the explanation and feel like I have a rough understanding of what is going on here. Does anyone know if AMD CPUs are affected?
- purpleidea 3y agoIn this new Intel microcode bug, Tavis writes: "We know something strange is happening, but how microcode works in modern systems is a closely guarded secret." My question: How likely is it that this is an intentional bug door that was added into the microcode by Intel and its government partners? I don't know enough about microcode and CPU's to be able to answer this myself, so backed-up opinions welcome!
- jsnell 3y ago0%. This isn't how anyone would backdoor a CPU. An actual backdoor would be done via some instruction sequence that is basically impossible to trigger by accident and hard to detect even when triggered.
- fsflover 3y agoCan you give an example of such sequence? Is it really so easy to hide it given that the microcode can be decoded in principle, https://news.ycombinator.com/item?id=32145324 https://news.ycombinator.com/item?id=32145324? Why is hiding it in a "bug" a worse solution? Why you can't do both?
- jsnell 3y agoHere's a couple of plausible ways. One is to make the condition for the backdoor trigger based on multiple (unlikely) instructions in sequence. This bug was triggered by a single instruction, so it would have been a pretty easy case for fuzzing. If you need a sequence of 10 specific instructions in a specific sequence, with no kind of observable side-effects for getting just the first 9 right so that nobody can do a guided search? That's not going to be found just by random chance. It doesn't matter what those instructions are, as long as they're not something that would get generated by real compilers on real programs. The other is to make it dependent on the data rather than just the static instructions. Like, what if you had the SHA1 acceleration instructions trigger a backdoor iff the output of the hash is a certain value? You could probably even arrange for the backdoor to get triggered from managed and sandboxed runtimes like Javascript, rather than needing to get the victim to run native code. And somebody triggering this by accident would be equivalent to a SHA1 preimage collision.
- ChrisRR 3y agoI really think HN rules should disallow titles like this. It tells me nothing about what the link is, the URL is even more confusing. I think for such meaningless titles that the poster should add a small description
- hombre_fatal 3y agoI disagree. We’ve seen what happens when titles have max context: people don’t click the link and they polish their semi adjacent hobby horses in the comments as they would a tweet. HN goes for a middle ground that promotes intellectual curiosity and link clicking. If you refuse to click the link for obscure titles at least you’re stuck replying to those who did click the link and that’s still better than what we have on the rest of the internet. Submissions that don’t have the payoff to justify more obscure, whimsical titles fall off the first page unlike this one.