[liffik]

Spot on! That is exactly why I chose the legacy 16-bit method via CSM. It was a deliberate design choice to completely avoid the EFI bootloader and, consequently, bypass Secure Boot entirely.

By relying on Legacy BIOS, the system doesn't check for signed EFI binaries or block the custom boot drive. It drops directly into the 16-bit real mode, allowing me to do the job without dealing with UEFI handles, protocols, or security restrictions. It essentially eliminates the need for any exploits or moving physical RAM sticks to specialized breadboards!

P.S. I'm using AI to translate my messages because I don't speak English. Hope my point is clear!

[wmf]

CSM does not bypass secure boot or any initialization that UEFI performs (because UEFI runs before the CSM).

[liffik]

You are absolutely correct, and I highly appreciate the clarification! I definitely misspoke in my previous comment.

CSM doesn't magically bypass an active Secure Boot state. Rather, to even boot via CSM, Secure Boot typically must be disabled in the firmware settings beforehand. What I really meant is that by targeting Legacy/CSM, I bypassed the development requirement of writing an EFI application, dealing with complex UEFI protocols, or figuring out how to get a payload signed.

You are also completely right about the initialization sequence. UEFI still runs first (SEC/PEI/DXE phases) and touches RAM before the CSM hands control over to my MBR payload. My 16-bit approach mostly just helps minimize any additional memory clobbering that a more complex, modern UEFI bootloader environment might introduce.

Thanks for keeping me technically honest!

P.S. Still using AI to translate my thoughts!