61–70 of 94 posts
Earlier quoted context omitted.
Then definitely also check out the Quantum Thief trilogy, by Hannu Rajaniemi.
Amusingly, the cover of The Quantum Thief (at least on iBooks) has the following quote: > "The best first SF novel I've read in years. Hard to admit, but I think he's better at this stuff than I am." -Charles Stross
found another that is QEMU-specific. https://github.com/unicorn-engine/unicorn/issues/364
Earlier quoted context omitted.
Thanks. The scale is still hard to wrap my head around but I see what you're saying. Could this tool find hardware backdoors?
> Could this tool find hardware backdoors? Only very crude ones. A competently implemented hardwre backdoor would probably be data-dependent. For instance, it might trigger when REP CPUID is called with four specific 64-bit values in R8, R9, R10, and R11 -- and if that were the case, there would be absolutely no way to discover it by searching.
Related: https://www.theregister.co.uk/2013/05/20/intel_chip_customiz... "Everybody hates the golden screwdriver upgrade approach, where a feature is either hidden or activated through software, but the truth of the matter is that chip makers have been doing this sort of thing for decades – and charging extra for it." ""We are moving rapidly in the direction of realizing that people want unique things and they are go…
>> "several million" undocumented instructions.. is that right? Bear in mind that doesnt really mean that there are several million operations / opcode mnemonics which are undocumented but each distinct instructions. It is more likely they are "loose" decodings of other instructions, where changing a single bit of the opcode still causes the CPU to decode the same instruction. Toy example: If I encode my (imaginary I…
A CPU is, at root, a massive Boolean circuit wrapped in a flip-flop and some persisted state. The binary [sequence corresponding to an] opcode is just an input that determines which inputs go where.
Thus, for an n-bit opcode width, there are 2^n valid opcodes. Only m of them will correspond to intelligible, "I might want to use that some day" instructions. (Others, as you note, will be functionally equivalent versions of the m and ignorable as well.)
And so you will have 2^n - m "undocumented opcodes".
[1] based on reading NAND to Tetris
Earlier quoted context omitted.
If anything, I'd expect such a flag to hide behind MSRs ( http://wiki.osdev.org/Model_Specific_Registers ) That's a mostly unused namespace of 2^32 64bit registers. To hide things even better, it would also be possible to change behavior based on officially unrelated registers (eg. MSR $x only acts as IME-switch if the calling address also ends in $y and esi is $z)
They could also be multiplexed (MSR $x is address/command, MSR $y is data). Or require a sequence of operations (write this magic sequence of numbers to MSR $z). Or memory-mapped/IO-mapped (with the mapping enabled/disabled by MSR or PCI registers). Or be locked by the BIOS during the boot sequence. But IMO, it probably can't be disabled at all. The "disabling" would be to change the program it runs to a program whic…
tl'dr of the slides: Found on one processor... instruction Single malformed instruction in ring 3 locks Tested on 2 Windows kernels, 3 Linux kernels Kernel debugging, serial I/O, interrupt analysis seem to confirm Unfortunately, not finished with responsible disclosure No details available [yet] on chip, vendor, or instructions He's found a new f00f bug, winter 2017 is going to be interesting :)
Observation: the length of the censored "XXX hardware bug" text on the slides matches neither Intel, AMD nor Transmeta. Unlikely to be VIA too. Either it's deception or perhaps some obscure low-end embedded vendor. edit: for the curious, it's "(redacted) hardware bugs" :)
tl'dr of the slides: Found on one processor... instruction Single malformed instruction in ring 3 locks Tested on 2 Windows kernels, 3 Linux kernels Kernel debugging, serial I/O, interrupt analysis seem to confirm Unfortunately, not finished with responsible disclosure No details available [yet] on chip, vendor, or instructions He's found a new f00f bug, winter 2017 is going to be interesting :)
If I was a betting man I would say ARM.
This is great. That a program can learn about and exploit the CPU on which it is running from unprivileged userspace reminds me of the notion in Charlie Stross' Accelerando of running a timing attack against the universe to learn about the virtual machine in which we are being simulated.
I believe there was also a Rick & Morty episode about this (of course...)