the latter Apple support article on Secure Boot has been updated recently:
I just noticed this nice document on Ubuntu security features, maybe it is new, maybe I never noticed it before:
I also notice this page, which I believe has recently been updated:
DKMS modules need to be configured to work with UEFI Secure Boot
Ubuntu is now checking module signing by default, on kernels 4.4.0-18.34, 4.4.0-21.37, 4.2.0-42.49, 3.19.0-65.73 and 3.13.0-92.139 onwards. You can read more details in this bug in Launchpad. Because of those changes, DKMS modules will not work on systems with Secure Boot enabled unless correctly configured. In order to make DKMS work, Secure Boot signing keys for the system must be imported in the system firmware, otherwise Secure Boot needs to be disabled. There are several methods to configure your system to properly load DKMS modules with Secure Boot enabled.
I believe this is a new (or revised) document [to me].
[…]VMware Tools version 10.1 or later is required for virtual machines that use UEFI secure boot. You can upgrade those virtual machines to a later version of VMware Tools when it becomes available.
For Linux virtual machines, VMware Host-Guest Filesystem is not supported in secure boot mode. Remove VMware Host-Guest Filesystem from VMware Tools before you enable secure boot.[…]
Cryptology ePrint Archive: Report 2018/427
Secure Boot and Remote Attestation in the Sanctum Processor
During the secure boot process for a trusted execution environment, the processor must provide a chain of certificates to the remote client demonstrating that their secure container was established as specified. This certificate chain is rooted at the hardware manufacturer who is responsible for constructing chips according to the correct specification and provisioning them with key material. We consider a semi-honest manufacturer who is assumed to construct chips correctly, but may attempt to obtain knowledge of client private keys during the process. Using the RISC-V Rocket chip architecture as a base, we design, document, and implement an attested execution processor that does not require secure non-volatile memory, nor a private key explicitly assigned by the manufacturer. Instead, the processor derives its cryptographic identity from manufacturing variation measured by a Physical Unclonable Function (PUF). Software executed by a bootloader built into the processor transforms the PUF output into an elliptic curve key pair. The (re)generated private key is used to sign trusted portions of the boot image, and is immediately destroyed. The platform can therefore provide attestations about its state to remote clients. Reliability and security of PUF keys are ensured through the use of a trapdoor computational fuzzy extractor.
We present detailed evaluation results for secure boot and attestation by a client of a Rocket chip implementation on a Xilinx Zynq 7000 FPGA.
System x Secure Boot Vulnerability
Lenovo Security Advisory: LEN-20241
Potential Impact: Booting unauthenticated code
Scope of Impact: Lenovo-only
CVE Identifier: CVE-2017-3775
Lenovo internal testing discovered some System x server BIOS/UEFI versions that, when Secure Boot mode is enabled by a system administrator, do not properly authenticate signed code before booting it. As a result, an attacker with physical access to the system could boot unsigned code. Lenovo ships these systems with Secure Boot disabled by default, because signed code is relatively new in the data center environment, and standard operator configurations disable signature checking. Apply the BIOS/UEFI update appropriate for your model described in the product impact section below. If you are relying on Secure Boot, you may want to control physical access to systems prior to applying the updates.[…]