| ▲ | estimator7292 9 hours ago | ||||||||||||||||
The Linux kernel contains biiiig piles of hacks for individual motherboards, systems, devices. It's like this at every level everywhere, unfortunately. I mean, it was only very recently that your 64 core CPU stopped pretending to be an 8086 during initial boot | |||||||||||||||||
| ▲ | codedokode 4 hours ago | parent | next [-] | ||||||||||||||||
Unlike Microsoft's hacks, these hacks do not include self-modifying code as I understand. I hope code with "detours" (a beautiful French-sounding euphemism for monkey-patching) is not accepted in Linux kernel and libraries. | |||||||||||||||||
| ▲ | leeter 4 hours ago | parent | prev [-] | ||||||||||||||||
> it was only very recently that your 64 core CPU stopped pretending to be an 8086 during initial boot Still Does[1]: >> After a RESET or INIT, the processor is operating in 16-bit real mode. Normally within real mode, the code-segment base-address is formed by shifting the CS-selector value left four bits. The base address is then added to the value in EIP to form the physical address into memory. As a result, the processor can only address the first 1 Mbyte of memory when in real mode. The UEFI hands off the boot CPU to the OS loader (GRUB/NTLoader etc) in long mode. But when the OS brings up any CPU that is not the initial bootstrap CPU via the interprocessor interrupt... that CPU comes up in 16bit* real mode. [1]: https://docs.amd.com/v/u/en-US/40332-PUB_4.08 (the intel one says the same thing last I checked, Intel has discussed changing this... but AFAIK has not yet) * This is a lie... note how the quote references EIP and not IP? That's because it's actually booting up in Unreal mode. Hence the initial instruction run is actually at 0xFFFF_FFF0 IIRC | |||||||||||||||||
| |||||||||||||||||