Related: <a href="https://cloud.google.com/blog/products/identity-security/google-researchers-discover-reptar-a-new-cpu-vulnerability" rel="nofollow noreferrer">https://cloud.google.com/blog/products/identity-security/goo...</a><p>(via <a href="https://news.ycombinator.com/item?id=38268043">https://news.ycombinator.com/item?id=38268043</a>, but we merged the comments hither)
Reading this makes me realize how little I know of the hardware that runs my software<p>> Prefixes allow you to change how instructions behave by enabling or disabling features<p>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?
Their diagnosis reminds me of what happened when qemu ran into repz ret. <a href="https://repzret.org/p/repzret/" rel="nofollow noreferrer">https://repzret.org/p/repzret/</a>
I really think HN rules should disallow titles like this. It tells me nothing about what the link is, the URL is even more confusing.<p>I think for such meaningless titles that the poster should add a small description
This 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.<p>Does anyone know if AMD CPUs are affected?
If 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.<p>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.<p>I expect Intel's CPU team isn't going to divulge the details though. :-)
I don't understand "ERMS" and "FSRM" and there seems to be nothing good on google about it.<p>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?
I noticed the Intel advisory [1] says the following<p>Intel would like to thank Intel employees:[...] for finding this issue internally.<p>Intel would like to thank Google Employees: [...] for also reporting this issue.<p>[1] <a href="https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00950.html" rel="nofollow noreferrer">https://www.intel.com/content/www/us/en/security-center/advi...</a>
See also Intel’s advisory, which has a description of impact: <a href="https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00950.html" rel="nofollow noreferrer">https://www.intel.com/content/www/us/en/security-center/advi...</a><p>> 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.
Konrad Magnusson from Paradox Interactive (Victoria 3) team found something related to that and mimalloc -> <a href="https://github.com/microsoft/mimalloc/issues/807">https://github.com/microsoft/mimalloc/issues/807</a><p>Not sure if fully related, but possibly.
Any reason to why its named after the dinosaur from the cartoon Rugrats? Or was that what was on TV at the time?<p>Maybe I should start hacking while watching Teenage Mutant Ninja Turtles.
Is 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?
It's going to be a pain for cloud and shared hosting.<p>Most likely dedicated resources on demand will be the future. Some companies already offer it.
The 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?
Benchmarking 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.
This 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?
Nice 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.)
Intel 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?
> the processor would begin to report machine check exceptions and halt.<p>I get it <a href="https://www.youtube.com/watch?v=dXekDCcw2FE">https://www.youtube.com/watch?v=dXekDCcw2FE</a>
The most awesome part:<p>> This bug was independently discovered by multiple research teams within Google, including the silifuzz team and Google Information Security Engineering.
Can 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.
Dupe: <a href="https://news.ycombinator.com/item?id=38268043">https://news.ycombinator.com/item?id=38268043</a><p>(As of this writing, this post has more votes, the other has more comments)
In this new Intel microcode bug, Tavis writes:<p>"We know something strange is happening, but how microcode works in modern systems is a closely guarded secret."<p>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?<p>I don't know enough about microcode and CPU's to be able to answer this myself, so backed-up opinions welcome!
It 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%?<p>In a duopoly market there seems to be no real competition. And yes I know that some (not all) bugs also happen for AMD.