What I mean is that arrangement could support things like third party unsigned BlueZ PAN and DUN support which was mentioned. That would run in the no-DRM environment. As long as it doesn't need kernel changes, only system daemons, that could be made to work.

Even some third party open source kernel modules may be possible, if there's a way to isolate them by running them in a kernel in a VM guest which has controlled access to host subsystems and devices.

Ideally the security module keeping DRM and no-DRM sides apart, with only safe interactions, should stick to the bare minimum of necessary restrictions. Preferably choosing the restrictions based on what DRM-using apps require at the time.

For example, the no-DRM side should be able to intercept all network packets in and out and, say, run it through it's iptables or fancy routing/tunnelling, just as it can now on Maemo 5 as root; there is no reason to block that sort of thing.

But the no-DRM side would be blocked from modifying files that the DRM side says it requires to be signed and managed by signed programs (all the way down to the kernel), and if the no-DRM side changed any of those files (including the kernel) or break any other invariants requested by a DRM-using app, then the DRM side would see the signature for those invariants is not available.

In summary, there's some scope for more fine-grained side-by-side behaviour than simply booting into DRM vs. no-DRM modes. It can resemble more closely a finer grained traditional or role-based security module, with signatures for fine-grained invariants which DRM-using apps request, which are granted only of no apps is breaking them at the time (or might have broken them earlier, depending on the particular invariant). And switching between modes can be more fine grained too.

The one thing which seems unavoidable is third party open kernels may not be able to provide any invariants to DRM-using apps - unless there is some trick of the hardware which can do that which is beyond even the kernel to defeat.