Rebooting with JMP Instruction (2003) | Hacker News Reader

Rebooting with JMP Instruction (2003)

susam.net

30 pointssusam15 comments

typically F000:E05B

That address is so deeply entrenched in history that one could even consider BIOSes which don't have the reset code starting there to be not PC-compatible. If you look at the PC/AT BIOS listing, it specifically puts the reset entry point there with an ORG directive. The BIOS reference books from Phoenix also mention that.

I believe even EFI BIOS in CSM mode will have the correct code at those fixed addresses, although it won't be obvious from just looking at the ROM image since it's packed and expanded into shadow RAM upon boot.

Here's some discussion:

https://forum.vcfed.org/index.php?threads/fixed-addresses-in...

> The important point worth noting here is that the very first instruction the microprocessor executes after booting is the instruction at FFFF:0000. We can use this fact to create a tiny executable program that can be used to reboot the computer.

This isn’t necessarily guaranteed, because some setup routines generally expect the computer to be in a certain state when run and may not like being run again. Typically most things will be reset to a sane state and will mostly work, but it’s not a given.

It isn't guaranteed, but I'd be shook if it didn't work I the cast majority of cases. Triple-faulting a CPU doesn't do much other than revert to real mode and jump to FFFF:0000, so I'd expect this to work too.

It's one of those not technically documented things, but a downstream effect of documented pieces.

Nit: "U" stands for "unassemble" (disassemble), not "undo."

Thanks. Fixed it!

I wrote about some of this in 2011 (https://mjg59.livejournal.com/137313.html), but even in 2003 this wasn't great advice - attempting to reboot a system like this would probably work most of the time, but it certainly wasn't guaranteed. The key point is that you're simply jumping back to the initialisation code, not actually resetting anything. If that code makes assumptions about hardware state then you'll end up with bad outcomes. The traditional way to reset PC-class machines for decades was to perform some register writes to the keyboard controller, which in turn would assert the reset line to the CPU. More modern systems don't necessarily even bother emulating a keyboard controller so that doesn't work so well, so instead there's an address on the motherboard chipset that'll usually trigger a reset, and this can be exposed via ACPI tables (although see the blog post I linked for more details).

But while it's not a great idea, would it still work on modern x86 that doesn't even have BIOS? Great question, but I suspect not. The CPU is still going to start reading instructions from the same address, but these days CPU state at the point of reading the first instruction is rather more complicated than it used to be. For instance, if you have an Intel system that has Boot Guard enabled, before the CPU starts reading anything from the reset vector it's already pulled an Authenticated Code Module out of flash and run that, and that's going to have set up Cache As RAM and enabled various other things, and it's much easier for modern firmware to make assumptions about that state than it would be if the OS just handed control back there. You're also going to be dealing with graphics hardware that's way more complicated than it used to be, and the question of whether the firmware driver for your graphics card is going to be able to reinitialise it from whatever state your OS left it in.

But more importantly - modern hardware has a whole bunch of "write once" bits, and if you simply jump back to init code without asserting reset, those aren't going to be cleared. Firmware code is going to expect to be able to access resources that it's no longer allowed to access, because those protection bits have been set and never cleared. A big part of that is System Management Mode, a bunch of protected code that runs on the main CPU but which can't be accessed by the OS. Jumping to firmware init isn't going to unlock access to the SMM region, and anything that's mediated by SMM is probably going to be inaccessible, so the firmware's going to have an extremely bad time.

I don't want to be too critical of the original post, which would probably work most of the time in 2003 (although even then a bunch of systems would probably break if you tried). But these days you really shouldn't have any expectation that this will work, simply because systems today are really pretty different to 20 years ago.

I’m suspicious that this doesn’t magically “reboot” by causing BIOS to POST and run the boot sequence. I suspect that it actually enters BIOS code with a horribly corrupt state, which causes a triple fault and resets the machine.

A triple fault reboots the system in a pretty similar way to a transfer to real mode as a jump, so I'd imagine it works pretty well actually.

On a modern system, it resets a whole lot of things, including state that firmware expects to have initialized and various lock registers that can’t be unlocked without a reset.

You can’t just run your system firmware kexec-style and expect it to work.

That's fair. The last time I looked into the space of what happens on a reset on x86, hardware roots of trust were significantly less important to the point of not really being on my radar.

IIRC (and assuing that since you all are still talking about a BIOS, this'll be backward compatible), asking the keyboard controller to reboot (was an 8042; no idea what emulates that now) was reliable, working on hardware as well as under QEMU. 0xFE?

https://wiki.osdev.org/%228042%22_PS/2_Controller#PS.2F2_Con...

INT 19h was my personal favorite, the .COM file can be reduced to 2 bytes that way.

Except that this doesn't work on many systems. I don't remember the exact details, but neither on my old 386SX nor on my 486SX this worked to reboot the system. On one it just printed "NO ROM BASIC", and on the other it just locked up the machine.

The JMP FFFF:0000 trick worked everywhere

It is very impressive when it works, though :) as the entire self-test portion is skipped and the machine should go straight to "Starting MS-DOS..."

Devices will be left in whatever state they were a moment before, so yeah.

Put 1234 in 40:72 (E 40:72 34 12 in DEBUG) before the JMP FFFF:0000 to do a warm reboot, this will bypass the self-test portion.

Reply on news.ycombinator.com