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

71–80 of 94 posts

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

#71

Post by wongarsu »

flopunctro wrote: post #33
dtx1 wrote: post #29

Earlier quoted context omitted.

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)

Some enterprise-grade server platforms already have this functionality, it's called a "watchdog". Linux supports this since (at least) 2.4. 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".

It would also be fairly simple to build for any computer using just an arduino or a raspberry pi. The computer could send a periodic signal over the serial port, if the arduino doesn't receive a signal for some time it shorts the mainboard's reset pin, causing a reboot.

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

#72

Post by anigbrowl »

winter_blue wrote: post #70
pmarreck wrote: post #44

Earlier quoted context omitted.

I believe there was also a Rick & Morty episode about this (of course...)

You mean the first episode of the third season where Rick breaks out of the virtual reality interrogation room he was in, by simply presenting some data (i.e. equations) that turned out to be code that took control of the system?

Posting spoilers is not clever.

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

#73

Post by [deleted] »

qubex wrote: post #37
d33 wrote: post #26

Earlier quoted context omitted.

What about hangs? I think you'd need a watchdog in order to have the process automated.

Firstly, the paper clearly explains that a userland (ring 3) process can easily discriminate between instructions that do not exist and instructions that the process lacks the credentials to execute simply because the two cases give rise to different exceptions (undefined and general protection, respectively). Secondly, one could trivially log "I am going to try this" to a file, go ahead and do it, and if the machine…

[deleted]

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

#74

Post by hamiltonkibbe »

flopunctro wrote: post #33
dtx1 wrote: post #29

Earlier quoted context omitted.

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)

Some enterprise-grade server platforms already have this functionality, it's called a "watchdog". Linux supports this since (at least) 2.4. 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".

You'd be hard pressed to find a processor without a WDT

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

#76

Post by qb45 »

azinman2 wrote: post #54
rasz wrote: post #47

Earlier quoted context omitted.

He works for spooks - Battelle Memorial Institute, a long-time NSA/CIA contractor. One of the places that hires officially retired spies.

and therefore.... ?

Therefore there is suspicion that spooks may have been using that for years and revealed it once they've had enough for some reason. I'm not familiar with any proven case of such situation, but people speculate.

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

#77

Post by winter_blue »

anigbrowl wrote: post #72
winter_blue wrote: post #70

Earlier quoted context omitted.

You mean the first episode of the third season where Rick breaks out of the virtual reality interrogation room he was in, by simply presenting some data (i.e. equations) that turned out to be code that took control of the system?

Posting spoilers is not clever.

Sorry, I should've just mentioned the season & episode number. Or nothing at all.

I would like to delete the comment, but it seems I just passed the 2-hour mark wherein editing/deletion is possible, and I can't remove it.

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

#78

Post by anigbrowl »

winter_blue wrote: post #77
anigbrowl wrote: post #72

Earlier quoted context omitted.

Posting spoilers is not clever.

Sorry, I should've just mentioned the season & episode number. Or nothing at all. I would like to delete the comment, but it seems I just passed the 2-hour mark wherein editing/deletion is possible, and I can't remove it.

Oh well, we've all made similar mistakes :)

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

#79

Post by thethirdone »

SilasX wrote: post #66
bem94 wrote: post #38

Earlier quoted context omitted.

>> "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…

Correct me if I'm horribly misunderstanding [1], but isn't there a more general point here? 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…

> 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.

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

#80

Post by SilasX »

thethirdone wrote: post #79
SilasX wrote: post #66

Earlier quoted context omitted.

Correct me if I'm horribly misunderstanding [1], but isn't there a more general point here? 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…

> 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?
Post reply on HN