|Ugh - 2017-09-10 |
good and all but scarey
|Rafiki - 2017-09-10 |
http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HIT OFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSr ch=yes&Query=PN/5701442
DBE0 and DBE1 are old 8086 opcodes, which x86 is derived from. f1 is literally in the reference manual, and was also part of 8086:
Other codes have been around for years and years as well. This was a half hour of Googling. Dude didn't look too hard.
Is there any reason to believe those opcodes do anything close to what they did on 8086? In any case, albeit relevant, I think your comment is beside his main point.
I think his point is more that we have little ways to verify the trust we put in the CPUs. Complete reference manuals are great and all, but they rarely are complete. At the very least this kind of tool will put some pressure on the manufacturers to not leave out any details (as innocuous as they may be).
Given that x86 is built from 8086 architecture and inherited its instruction set, I think it's more reasonable to ask if there's any reason to believe those codes DON'T do what they did on the 8086. Furthermore, it would be easy enough to verify. Run both instructions on each processor and check the results.
If his presentation was purely that he created a clever way to verify processor instruction sets, and that he found some instructions he wasn't sure what they were and offered them up as a way to crowdsource their meaning, that would be fine. The idea of independently auditing that hardware does what it's advertised to do is great. However, some of his conclusions are flawed, some of his claims are false and trivially provably so, and his presentation of his findings to the public is irresponsible. He's CLEARLY trying to strike a fearful tone, but I'm not convinced it's deserved.
Mostly it chaps my ass if someone publishes claims I can debunk in 2 seconds of googling in my underwear.
I can't watch the video right now but the idea is not without merit. It's well known Intel/AMD and the rest tend to have extra registers and other functions in cases there is problems, as well as microcode.
Which is used to reprogram a chip if there is issues.
Things are less hardcoded after their original fuck up with the FP look up table.
My bigger concern is side-channel attacks. It would be very difficult to verify if a certain chip leaked info via other means then hidden instructions in there.
| Register or login To Post a Comment|