[PopePompus]

Even so, doesn't having a more complex instruction set, festooned with archaic features needed by very few users, increase the attack surface for hacking exploits and increase the likelyhood of bugs being present? Isn't it a bad thing that the full boot process is understood in depth by only a tiny fraction of the persons programming for x86 systems (I'm certainly not one of them)?

[toast0]

As a sibling said, if you can get the cpu into real mode, you can probably do whatever else you want, so it being there isn't a real security worry.

Dropping real and virtual mode wouldn't save a whole lot anyway; for the most part, the instruction set is the same, regardless of mode, just register selection is a bit different, and fiddling with segment registers is significantly different.

Mostly, the full boot process isn't understood in depth by many people because very few people need to know about it in depth. Really full boot process includes detecting and enabling ram and all that, and there's a handful of companies that provide most of the firmware images for everyone ... OSes usually start from the BIOS boot convention or UEFI, so they don't need to know all that early boot stuff. Well, really, bootloaders start there, OSes can start at multiboot or UEFI if they want to save some work. An SMP OS will still need to know a little bit about real mode though, because application processors (non-boot processors) start in real mode, complete with segmented addresses, and need to get into protected mode themselves.

[jcranmer]

Not really. Basically none of these features can be used outside of the kernel anyways, which means that the attacker already has far more powerful capabilities they can employ.