DRM has long since trusted the kernel. Utilizing the TEE or other hardware based mechanisms for hiding the keys is common. For situations where that's not available they just simply don't offer degraded service.
If you wanted DRM keys, couldn't you just patch memfd_secret() to remove its security features, let the program use it, then have a look at the assigned memory?
Sure, on paper, that will always be possible - just not in the age of signed kernel images that are cryptographically verified by your immutable bootloader.
Windows Hardware Compatibility Program Specification mandates that Secure Boot can be disabled and customized, by a physically present user, on non-ARM platforms, in early versions of the Windows 10 spec.
Disabling Secure Boot must not be possible on ARM systems. - WHCP-Systems-Specification-1511.pdf
However, looking at the -2004 spec, both customization and enable/disable sections are prefaced with (Optional for systems intended to be locked down) so it is no longer mandatory, even on x86_64 systems, to provide a physically present user with the ability to disable or customize UEFI Secure Boot. The same language is used in the -21H2 spec for Windows 11.
So yes, some apps will refuse to run and in theory some services could refuse to accept requests from devices that aren't running unmodified images.
I can definitely imagine something like Snapchat using this as they have actually been fairly aggressive at trying to prevent "unauthorized clients" that can save images without notification to the user.
