The LG TV "custom kernel" did not break secure boot. Linux 4.4.3 has nothing behind it

kexec is ordinary plumbing. It is a syscall that loads a second kernel from inside the running one and jumps straight into it, skipping firmware and POST entirely ^[6]. Enterprise distros carry it because kdump needs it: when a box panics you kexec into a small capture kernel that writes the dead kernel's memory to disk, and that only works because skipping firmware means RAM is never wiped ^[7]. It is also how a large server reboots without waiting for firmware to count its own DIMMs, and it is the basis for kexec-based bootloaders such as Petitboot and LinuxBoot, where Linux's own drivers and network stack stand in for whatever the vendor shipped ^[8].

The part worth understanding is why the same move fails on a current Secure Boot machine. It used to work exactly this way. The old `kexec_load` accepts an in-memory image with no integrity checking whatsoever, so root holding CAP_SYS_BOOT could stage arbitrary bytes and enter ring 0, walking around the signed chain rather than attacking it ^[9]. Kernel lockdown, Matthew Garrett's work, merged upstream in 5.4 to shut that off ^[10]. Boot a mainstream distro with Secure Boot on today and the kernel enters lockdown, lockdown disables `kexec_load` outright, and the replacement `kexec_file_load` takes file descriptors and runs the kernel's own signature check, so only a validly signed image loads ^[11]. kdump keeps working because the capture kernel is signed ^[12].

That threshold sits above the version this television runs, and there is no toggle, command line or build flag that changes the arithmetic: the mitigation is not in that tree to configure ^[14]. LG's verification carries the chain up to the signed kernel and then stops caring ^[13], and after that point root and kexec are the same privilege.

So the honest accounting of what the signing chain still does for the owner: it covers everything before the kernel, which is why a bad build costs a reboot rather than a panel. What it never covered was the kernel that is actually executing, and the write-up's own framing is the correct one, according to Paul Asadoorian on PSW #940 - verified boot is a statement about how you started, not about what you are running now ^[5].

Which leaves the practical blocker on this project as a timer rather than a cryptographic one. Nothing in the signing chain is stopping a custom kernel on this hardware; the SoC watchdog is ^[15]. Whoever works out how to keep that watchdog fed will have a usable custom-kernel television, and they will not have needed a single key to do it.