It's more insidious than that. The big distros have been signed and will probably work, but recompiling your kernel, using less common distros, or using third-party modules won't.
If they're signing Ubuntu's ARM shim loader the same way they're signing Ubuntu's x86-64 shim loader, you can use it to boot an arbitrary kernel in non-EFI mode. I am using this on my personal laptop to to boot Debian stable with Debian's kernel - grab shimx64.efi + grubx64.efi from Ubuntu, put them in the ESP, and write a little grub.cfg that sets $root and $prefix to the Debian partition and runs `normal`. Since you're exiting UEFI boot services before running unsigned code, Microsoft (apparently?) does not care.
Also, if they're signing any Linux distro's shim loader, shim allows a physically present user to enroll their own key or disable secure boot. See method 3 at https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS .
In theory, if you enable signature checking in Grub, sign your kernel, add that key to Grub, sign Grub, import that key into the UEFI, delete all the stock (Microsoft) keys and use full disk encryption (use the luks module in grub and place an unlocking key in the initrd) .. then in theory, it should be very difficult for someone to reformat and fency your stolen laptop.
I've got the full disk encryption working with luks/grub (you do have to unlock the device twice, one for grub to read its stage2 and one in the initrd for the kernel), I just haven't gotten around to trying to re-enable secure boot.
I get that. But as you can surely see, this is not a common use case at all. Less than 1% (number pulled out of the ass) of regular consumers get their laptop stolen. Then among those, very little percentage of people actually care (enough to pay somebody to to secure the laptop properly) about the data stored in the machine. Mandating secure boot and making legit consumers to go through all that just to run their own os is simply bullshit. It's just a method to lock down the machine.
Your ass-pull laptop theft rate of 1% is still roughly four times the use rate of Linux in the Steam Hardware Survey. Installing your own OS is not a common use case at all, either.
That doesn't really change the point much, does it? Installing your own non-Windows OS on a machine is a very small part of the market. Providing security for the people who will never install a new OS on their machine (not even a new version of Windows) is serving a much larger part of the market.
Providing security for the much larger part of the market does not mean, that it is necessary to lock out the minority.
Otherwise, why have the antitrust laws at all? The dominant market players provide useful services, why should we care about the minor players? (Not only in operating systems, but in general).
It sounds like it makes sense if you look at it from the perspective of Microsoft wanting to hold onto the keys in case they ever want to lock the door.
And fair's fair, Microsoft was the one that pushed UEFI so hard.
Which? The first one (the one I'm running on my laptop) doesn't involve custom mode at all - I'm using an MS-signed bootloader to exit boot services and do some stuff, with no changes to SecureBoot or PK or any other variables. I have an actual Secure Boot-enabled platform with only Microsoft keys enrolled.
The rest involve changing EFI variables, yes, but my impression is that "Custom Mode" refers to a UI in the BIOS which permits you to change the variables, and those variables are always writable by code running in boot services. The requirements say, "On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: 'Custom' and 'Standard'." Nothing I'm suggesting involves going to firmware setup.
If so, sorry MS - this is a great step, but no sale yet.