Secure Boot does not implement DRM or help in any way for DRM, as it turns out. Secure Boot is about the hardware trusting the OS it's about to boot, not about the OS trusting the hardware it's running on. Once the OS has booted, it has no way to figure out if the "you were secure-booted" flag is trustworthy or not -- a trojan bootloader can easily set that flag and then chainload to the normal OS.
If you want the OS to trust the hardware it's on, you need a TPM, and you probably need the machine to be installed by someone who can communicate with the content provider. The entire point of Secure Boot is that it can be implemented just in existing UEFI code, _without_ the additional hardware of a TPM.
I develop an OS product that has no browser installed on it at all -- there's one small client application that just interacts with our one server product, and then boots everything else you might want to do in a VM. The biggest threat to the security of our outer layer is, in fact, an evil maid attack. It's certainly worth being aware of that threat, even if there are other, bigger threats. (Nobody says that we should stop worrying about buffer overflows while there are still cross-site scripting attacks, etc.)
I didn't say it "works". What I said was basically: Secure boot answers the question "How do I know someone won't write a crack to steal my content?" in an intelligible way (i.e. "Because it locks down all the software that runs on the device in an uncrackable way.")
That's a powerful sales tool. Systems that don't have secure boot have a much harder time selling their DRM implementations. And that's why we have secure boot. Don't fool yourself into thinking all problems are technical.
If you want the OS to trust the hardware it's on, you need a TPM, and you probably need the machine to be installed by someone who can communicate with the content provider. The entire point of Secure Boot is that it can be implemented just in existing UEFI code, _without_ the additional hardware of a TPM.
I develop an OS product that has no browser installed on it at all -- there's one small client application that just interacts with our one server product, and then boots everything else you might want to do in a VM. The biggest threat to the security of our outer layer is, in fact, an evil maid attack. It's certainly worth being aware of that threat, even if there are other, bigger threats. (Nobody says that we should stop worrying about buffer overflows while there are still cross-site scripting attacks, etc.)