SMAF Still Hasn't Landed In Linux Kernel, Would Allow Better Protecting Video Playback

[starshipeleven]

sigh, unapproved post for Guest above this one

[Luke]

Any chance this could be used to sandbox cryptsetup volumes as a defense against online attackers using root exploits to export disk keys? Remember that if there is suspicion a disk key has been compromised the volume has to be re-encrypted from scratch and all space used overwritten. Just changing the passphrase does not change the disk key itself.

[ssokolow]

Theoretically my ass. This is a framework that isn't specific to DRM, and anyone can use for other things too.

The ability to restrict access to hardware or restricting access from hardware is just another security feature.

"theoretical" in the sense that developers actually have to make use of it, which is something I doubt.

It's been over 15 years since AMD introduced the NX bit to the x86 world (the AMD64 spec was published in 2000) and it was less than a year ago when I saw a Planet Mozilla blog post that boiled down to "For enhanced security, we're finally trying to get SpiderMonkey to manage NX bits on JIT-generated pages, rather than leaving them unprotected".

[starshipeleven]

"theoretical" in the sense that developers actually have to make use of it, which is something I doubt.

Adoption rate of new features that require thought has always been slow. Just look at how much time we are taking to just kill off 32bit for good in programs.

[pal666]

I'm fine with it, as long as there is like, a build time switch or something to let us bypass it :-P

don't watch drm'ed videos and it will not be used

[DrYak]

Practical applications:
- avoid recording of un-authorized part of the screen.

E.g.: a screen sharing application going rogue (because of bugs) and starting to share the whole desktop.
With such a secured path, you could restrict Skype/WebEX/AdobeConnect/whatever other shit/etc. to only live stream the application that you want to show.

E.g.: someone finding an exploit in WebGL implementation in browser and finding a way to start dumping texture memory (and thus snooping on what else is composited on screen). Basically, the same situation as above, except that instead of a bug in an official screencasting software going berzerk, it's a remote exploit turning your browser into a spying screencasting webapp.


All these are security problems, not Digital Restriction Management.
All these are theoretical security problem that are considered by security researcher, sometime with some limited proof of concept code.
All these could be one day abused by three-letter-agencies to violate your privacy.

SMAF could complement IOMMU as a way to prevent such unauthorized access (either by bug or by remote exploits) to your screen and privacy.

[ssokolow]

Practical applications:
- avoid recording of un-authorized part of the screen.

E.g.: a screen sharing application going rogue (because of bugs) and starting to share the whole desktop.
With such a secured path, you could restrict Skype/WebEX/AdobeConnect/whatever other shit/etc. to only live stream the application that you want to show.

E.g.: someone finding an exploit in WebGL implementation in browser and finding a way to start dumping texture memory (and thus snooping on what else is composited on screen). Basically, the same situation as above, except that instead of a bug in an official screencasting software going berzerk, it's a remote exploit turning your browser into a spying screencasting webapp.


All these are security problems, not Digital Restriction Management.
All these are theoretical security problem that are considered by security researcher, sometime with some limited proof of concept code.
All these could be one day abused by three-letter-agencies to violate your privacy.

SMAF could complement IOMMU as a way to prevent such unauthorized access (either by bug or by remote exploits) to your screen and privacy.

Thank you. It's very reassuring to have concrete examples like that.

[benjiG]

version 10 of SMAF just post on mailing list:

http://www.spinics.net/lists/kernel/msg2355270.html

commit message have been change to clarify the use cases.