Hacker News Reader

Comment by askvictor | Hacker News Reader

As the slides say, this approach prevents the system from falling over entirely, while still resolving instructions from deeper rings.

View on HN

Makes sense. I was thinking if there could be a bootable fuzzer of this kind, but you're right that it would be very difficult for it to be both usable and not crash very quickly.

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.

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)

Sure, just have the 'os' ping the external device in N second intervals. Without a ping, reset through a jumper.

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

I think they are common on Intel systems, my old laptop with ICH7-M chipset has one.

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.

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

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

Reply on news.ycombinator.com