Kernel lockdown vis-à-vis secure-boot

I've written a number of remote exploits (white-hat; merged in Metasploit), and the ability to modify the boot chain is not as easy as the lockdown authors claim. It might be much easier in the servers world due to extreme PC boot-protocol standardization, but it's hard as hell in the embedded world due to esoteric SoCs, unknown custom-built boot-loaders, and read-only storage.

In these cases, and even without secure-boot, basic kernel hardening features like disabling /dev/mem, /proc/<pid>/mem, /proc/kcore, etc. etc. are __invaluable__ in making the attackers life much harder -- even if they got execute access as UID 0.

Yes, with UID0 the attacker can create a kernel module to re-expose all that, but again this is embedded: (f)init_module() might be removed from the kernel. Even funnier: you might only have a root _shell_ access, but not pure uid 0 binary execution context; and then you find yourself with a busybox having wget and insmod removed ;-) You try to write your exploit ELF, byte by byte, using 'echo' to a tmpfs partition; on a lot of devices this will succeed, but others might have a brain-dead 'echo' version that does not support the necessary "-en" parameters, and so on.

So, honestly, Linus is __absolutely__ right:

"Because as long as the explanation is just some 'you must use secure boot or you've already lost and further security is pointless' hocus-pocus magical thinking, I immediately go 'no, that sounds completely bogus and it makes testing and coverage much worse, we've done other things quite like that without this secure boot tie-in'".