alt Hacker News>and keep shipping mandatory DRM modules that run with deranged levels of privilege in places like TrustZone
What's "deranged" about TrustZone? It's just a way to allow code to be executed in a tamper-proof way. Advocates like Stallman might object to this on the basis of "freedom to tinker" and "user control", but it can't steal your data, which is what "deranged levels of privilege" sounds like.
Moreover it's not too hard to imagine DRM implemented in a way that doesn't have those issues. The most obvious example would be some sort of dongle that handles decryption and forwards it to a TV. In other words, a chromecast. It'll still be a black box, but I doubt anyone seriously cares. You can make a case about how your computer or smartphone should be "open", but the case is far less persuasive for a media dongle.
Replies
In ARM, TrustZone[0] is a higher level of privilege than hypervisors (EL3 vs. EL2); it's morally equivalent to x86 System Management Mode. That means it categorically can steal your data. There's nothing EL2 code can do to prevent inspection or manipulation from a malicious EL3.
A less awful design would have been to keep the security code at EL2 and have CPU hardware that can isolate two EL2s from one another[1]. This is ultimately what ARM wound up doing with S-EL2, but you still need to have EL3 code to define the boundary between the two. At best the SoC vendor can design a (readable/auditable!) boot ROM that occupies EL3 and enforces a boundary between secure and non-secure EL2s.
[0] Or, at least, TrustZone's secure monitor. TZ can of course run secure code at lower privilege levels, but that doesn't stop a TZ compromise from becoming a full system compromise.
[1] If you're wondering, this is morally equivalent to Apple's guarded exception levels.
Every other exploit chain that the likes of Cellebrite use to pry the user data encryption keys out of TZ starts in some shitty DRM module.