Just like DVD's css and Blu-Ray DRM, once again a corporate attempt to control what people do with what they have already bought and paid for has been defeated!
Should be easy enough to reconfigure Fedora (or anything else) to permit kexec with secure boot, say for a machine with a locked/buggy UEFI that does not permit turning Secure Boot off. For this a signed kernel NOT booting into any kind of Secure Mode would be booted with secure boot still activated. I think this is Ubuntu's default approach, as it makes the use of proprietary or other third party drivers much easier, as they do not have to be signed. Ubuntu Server should probably offer an option to change that, however. After all, blocking unsigned modules (or ALL modules) is an established technique to harden any system that will be run only with known hardware, such as a server, and is ineffective if a reboot to an arbitrary kernel is possible. Ideal approach would be a boot-time only option for secure mode or not, on the same signed kernel bootable from UEFI with Secure Boot enabled.
I could see cases, such as UEFI only accessable from inside Windows, where a kexec-style exploit is needed to essentially root your laptop. Still chicken-and-egg if starting from Linux on machines that offer no option to stop Windows 8 from booting and have a soldered-down disk, however. The other problem is machines like the MS Surface, with no option to run anything but Windoze. For these, a port of kexec to the Windows kernel would allow rebooting to Linux, either for a session or to load code to root the firmware to install other keys and/or disable Secure Boot. That will be the final crack of Secure Boot as a form of DRM. It took 6 months for someone to jailbreak the first iPhone, and they got a blizzard of bluffing threats from Crapple as I remember. Now rooted phones are everywhere, and Hollywood is crying.
I can really only see one reason to keep Secure Boot, given than kexec can reboot into Windows 8 or later. This would be for an attempt to obstruct the insertion of software keyloggers into /boot on encrypted machines. In the wild, the MSS(China secret police) is known to prefer hardware keyloggers, even on laptops. Suspect the same of the FBI, so this would be no guarantee even if it was perfect. The "evil maid" software keylogger is simple in theory but in practice in the field easy to run into surprises while trying to implement against unknown machines where you don't even know in advance what OS you will be facing, this the popularity or hardware keyloggers.
Just don't count on that TPM not to have additional, hidden keys for the NSA and maybe the FBI the way MS Windows itself and ATA security set password commands do. If it does, they
could sign their "evil maid" initramfs with that key instead of yours. Thus, we need an open-hardware TPM next, the kind you can drop into the motherboard socket and epoxy down. Only then will there be any "secure" in Secure Boot when the NSA (or possibly the MSS) is the adversary.
Until then, we gain much and lose almost nothing from exploits against Secure Boot. Its not secure, as the hardware itself cannot be trusted.
You're basically saying you could break Secure Boot by launching a kernel that isn't approved that includes kexec - which implies you've already bypassed Secure Boot.
You either turned it off, or managed to key sign that kernel yourself to work, in which case there is no reason to use kexec to bypass anything, since you already have.
Of course, in any machine supporting "custom mode," keys can be changed, allowing you to sign any kernel you want to run and make sure is being used. Just because Fedora is by default configured to use Secure boot with its kernels and its keys (don't know if that is an MS key) does not mean a user can't modify it to use their keys and their kernel, so long as they install their own keys in the TPM. Bootloaders can be changed to ones that are themselves signed, call ExitBootServices themselves, then run unsigned kernels. In this scenario, you would be using kexec for some other purpose than cracking secure boot, such as a gamer wanting to boot into Windows directly from Linux. You could boot Windows 8 with a custom kernel and unsigned drivers, as though it were running under Stoned Bootkit, then crack DRM'ed Hollywood content, while Windoze Media Center still thinks it has a "protected audio path," etc. You might have this whole mess running in a VM but thinking it is on bare hardware while the hyperviser harvests the content for your backup files. In the latter case you are cracking Windows, not Secure Boot.
Now I will point out an example of where you do NOT want kexec to be available: an encrypted machine such as a server that has to run unattended. Not a good idea, but suppose you are relying on DDR3 RAM epoxied into the slots, plus a hard-to-enter locked case to kill the "freeze the RAM" cold boot attack, thinking that means DM-crypt gives protection Bitlocker with its forensic tools given to the FBI does not.
If the running kernel supports kexec, an attacker, (maybe even a remote attacker with a root shell from an exploit) could kexec to a new kernel and a special forensic OS, taking care not to overwrite RAM locations where the encryption key is likely to be stored, then extract the key without ever shutting down and risking RAM decay killing it. For this attack, a kernel not supporting kexec could be "updated" during a physical access visit to one that does, waiting for the next reboot. The reboot could be forced by an arranged power outage, etc. Secure boot and a system like Fedora could make that MUCH harder, but only if you are using your own keys and only if the TPM does not contain extra NSA/FBI keys hidden from you (as I assume it does).
Personally, I would rely instead on a room boobytrapped to shut off the power if entered to attack that server. Step on the pressure plate, short out both the AC mains and the UPS, trip both breakers. Remote attacks remain an issue, but no physical access attacker could recover in time, especially worrying about securing the room before even attemping any further hacking. By the time they are back at the machine, that RAM has been powered down probably half an hour.
And what "security benefits" would those be???could defeat any security benefits provided by Secure Boot
Oh right... secure is from the perspective of system builders, not the actual people who own the hardware.
In other words... HURRAH FOR KEXEC!!!
If this sounds like sarcasm or trolling, it isn't, I'm geniunely interested in reading about this... I just know it can be hard to tell on the internet about things like this sometimes, especially in places where trolling can be common like here.