Hm...<p>First, the slide shown in this article says "allow end user to turn off". It says nothing about "allow end user to add his own keys". If the end user can add his own keys, the end user can still bypass this mechanism; it's just a bit more complex and annoying.<p>Second, even if the firmware doesn't allow the user to add his own keys, there are bootloaders like SUSE's shim which are signed by Microsoft and allow the user to add his own keys for the next step (see <a href="https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_secboot.html" rel="nofollow">https://www.suse.com/documentation/sles11/book_sle_admin/dat...</a> for instance).<p>Of course, I wonder how long until shim doesn't work anymore (either by having its signature revoked or by Microsoft migrating to a new root key and not signing shim with it). Who knows, these Windows 10 requirements might already be using a new root key, instead of the one the shim bootloaders were signed with.<p>If end-users cannot disable secure boot (or add his own keys), they won't be affected at first, since the most popular Linux distributions have a signed bootloader. But when in secure mode, you can't boot your own self-compiled kernel, and often you can't even load unsigned drivers. This makes it harder to debug kernel issues (since you can't compile and install a modified kernel), and makes it hard to develop drivers for new hardware.