Grub itself is mostly written as a 32 bit program (almost it's own OS by now, actually). The x86 Linux kernel does expect to perform the protected mode switch on its own in the early assembly code right before the zImage decompression starts. So Grub has to switch back to real mode in order to jump into this part of the Linux kernel.
Grub has other ways to boot kernels. I once used a method that looks for a specific signature inside the kernel blob that would tell Grub to stay in 32 bit mode, put the blob at a certain memory address and jump into it. This was a feature of Grub 1 back in the day. I do not know if it was removed in Grub 2.
Thanks, yeah I guess I hadn't really thought about who flipped the protected mode bit Grub or the kernel before. It's documented here in the section "3.2 Machine state"
>"When the boot loader invokes the 32-bit operating system, the machine must have the following state
...
‘CR0’
Bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits are all undefined."[1]
However it sounds like Grub also understand the Multiboot Specification so can keep protected mode set if it's booting a kernel that expects it to already be set. It's not clear to me how Grub would determine that.
Grub has other ways to boot kernels. I once used a method that looks for a specific signature inside the kernel blob that would tell Grub to stay in 32 bit mode, put the blob at a certain memory address and jump into it. This was a feature of Grub 1 back in the day. I do not know if it was removed in Grub 2.