31–40 of 94 posts
Earlier quoted context omitted.
What about hangs? I think you'd need a watchdog in order to have the process automated.
I'm sure there are ways to read out a CPU Hang and reset if that happens, if necessary via external hardware^(I'm guessing)^(I don't actually know)
"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 going to want them in silicon. In some cases, it will be done in software," said Waxman."
Also, Github says "several million" undocumented instructions.. is that right? I don't know much about assembly but that number sounds absurdly high.
Earlier quoted context omitted.
What about hangs? I think you'd need a watchdog in order to have the process automated.
I'm sure there are ways to read out a CPU Hang and reset if that happens, if necessary via external hardware^(I'm guessing)^(I don't actually know)
I've been using this with HP ProLiant servers and (for me, at least) it has always worked as intended.
For more info, search "linux watchdog timer".
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 :)
Either it's deception or perhaps some obscure low-end embedded vendor.
edit: for the curious, it's "(redacted) hardware bugs" :)
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.
No instructions there to disable the IME?
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)
But IMO, it probably can't be disabled at all. The "disabling" would be to change the program it runs to a program which does nothing. So there wouldn't be a "disable IME" bit; there would be bits to either make its memory visible to the main CPU cores, or to read/write to its memory, and it's possible that these bits are accessible only from the IME side, or from SMM.
Earlier quoted context omitted.
I think once you found all possible instructions it shouldn't be too hard (for someone much smarter then me) to essentially generate a minimal OS that systematically tries out all found instructions from ring 0. That should dramatically reduce the amount of reboots necessary to actually try them all out compared to bruteforcing them from ring 3
What about hangs? I think you'd need a watchdog in order to have the process automated.
Secondly, one could trivially log "I am going to try this" to a file, go ahead and do it, and if the machine crashes you consult the log and read exactly what was about to be done and evidently caused a hang. You don't necessarily need to write a log entry after doing something, in this case you can deterministically log what you are about to do and make deductions therefrom.
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…
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 ISA) 8bit instruction for "ADD EAX EBX" as 0101_X000 where X is "don't care" then regardless of whether the core gets 0101_0000 or 0101_1000 , it will still execute the ADD instruction.
Now imagine your instructions can be upto 16 bytes long, and you see how loose decoding can lead to a lot of instructions which are undocumented, but that the processor is perfectly happy to execute.
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" :)
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…
Could this tool find hardware backdoors?