Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sandsifter: find undocumented instructions and bugs on x86 CPU

github.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#81

Post by collinmanderson »

tux1968 wrote: post #30
michaelmior wrote: post #24

Earlier quoted context omitted.

It would be even better if there was a web service that would collect these logs for different processors so everyone didn't have to invest the time to run the analysis.

Well they do mention in the description: The results of a scan can sometimes be difficult for the tools to automatically classify, and may require manual analysis. For help analyzing your results, feel free to send the ./data/log file to xoreaxeaxeax@gmail.com. No personal information, other than the processor make, model, and revision (from /proc/cpuinfo) are included in this log.

It would be nice if there were something like Geekbench where it publicly listed the results from different processors.

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#82

Post by wmu »

pwdisswordfish wrote: post #64

The slides mention an 'apicall' opcode 0ffff0; searching the web turns up nothing but these same slides. Does anyone know anything about it?

It seems to be a MS antivirus bug: http://securityaffairs.co/wordpress/60434/hacking/microsoft-...

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#85

Post by webreac »

duskwuff wrote: post #58
dtx1 wrote: post #8

This is highly interesting. I assume a lot of those are going to be debug and instructions to help the binning process. Some of these might even unlock access to parts of the CPUs we aren't supposed to have access too, opening the doors to custom microcode (unlikely that anyone outside the CPU OEM can do that though) but may allow us to disable "security features" such as the Management Engine. This is a really inter…

Separate research has been done on microcode. The general consensus is that Intel's microcode binaries are encrypted, and are secured with a RSA2048-SHA256 signature. http://inertiawar.com/microcode/

I am surprised private keys have never leaked.

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#86

Post by muricula »

SilasX wrote: post #80
thethirdone wrote: post #79

Earlier quoted context omitted.

> And so you will have 2^n - m "undocumented opcodes". Not quite, there will be 2^n - m possible opcodes, but not all of them will have functionality attached. Many may end up being illegal. So you could have a processor with m=400 and n=16, but no valid opcodes besides the 400. All 2^16 - 400, could throw an Illegal instruction exception.

So I must have some big misunderstanding then -- in what sense can a different binary input to a boolean circuit throw an illegal exception? How does the concept make sense at that level?

Processors have "traps" or "exceptions" which work kind of like interrupts. They are utterly unlike exceptions in say C++. They transfer control to another location you specify in an interrupt table. The most well known of these is the "page fault" which occurs when you write/read/fetch from memory you're not allowed to.

Say you have a userland process which dereferences a NULL pointer in C. In the CPUs page table the NULL virtual address is not mapped to a physical address, so a page fault occurs. Control transfers to the OS page fault handler which then delivers the SIGSEGV signal to the process.

There's also a division by zero exception, and several more. You can read more about them here: http://wiki.osdev.org/Exceptions

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#87

Post by SilasX »

muricula wrote: post #86
SilasX wrote: post #80

Earlier quoted context omitted.

So I must have some big misunderstanding then -- in what sense can a different binary input to a boolean circuit throw an illegal exception? How does the concept make sense at that level?

Processors have "traps" or "exceptions" which work kind of like interrupts. They are utterly unlike exceptions in say C++. They transfer control to another location you specify in an interrupt table. The most well known of these is the "page fault" which occurs when you write/read/fetch from memory you're not allowed to. Say you have a userland process which dereferences a NULL pointer in C. In the CPUs page table th…

That much makes sense, but the original framing of the opcode as illegal still comes off as a category error to me (though perhaps that phrasing is common and excepted). The opcode itself isn't illegal, as opcodes are a CPU-level concept, where nothing is illegal.

Rather, the opcode may bring the memory state to something that might violate some OS's security model. But the opcode still does something to the CPU (Boolean) circuit state.

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#89

Post by hellbanner »

duskwuff wrote: post #56
hellbanner wrote: post #40

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.

No way to discover because of the immense search space? And/Or that if the backdoor was triggered, no way to immediately detect its effects?

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#90

Post by sand500 »

SilasX wrote: post #87
muricula wrote: post #86

Earlier quoted context omitted.

Processors have "traps" or "exceptions" which work kind of like interrupts. They are utterly unlike exceptions in say C++. They transfer control to another location you specify in an interrupt table. The most well known of these is the "page fault" which occurs when you write/read/fetch from memory you're not allowed to. Say you have a userland process which dereferences a NULL pointer in C. In the CPUs page table th…

That much makes sense, but the original framing of the opcode as illegal still comes off as a category error to me (though perhaps that phrasing is common and excepted). The opcode itself isn't illegal, as opcodes are a CPU-level concept, where nothing is illegal. Rather, the opcode may bring the memory state to something that might violate some OS's security model. But the opcode still does something to the CPU (Boo…

You could think of it as a switch case statement where the valid opcodes are the cases and there is a default that catches all non defined opcodes and throws an error. Its illegal in the sense you should never expect to run an instruction with those opcodes.
Post reply on HN