If Malice's program has managed to get root on Bob's Linux environment, and part of that Linux environment (whether a driver built into the kernel, or a userspace program) is responsible for controlling the USB peripherals and authorizing requests for data from them, then she can just invoke the appropriate APIs for accessing the USB camera through "proper channels"; she doesn't need to access the USB host controller's registers. (And why would she want to? Dinking about with the USB host controller's registers would be a good way to make the system glitch in ways that induce Bob to do a clean install, at least temporarily cleansing Malice's program from the system.)
Now, if Bob is running a partitioning hypervisor (so that the Linux kernel is not absolute lord and master of his computer's MMU) with no software-based privesc bugs, and there are no privesc bugs in the underlying silicon, and the Linux partition doesn't have access to the USB host controller, then the partitioning-enhanced MMU has secured Bob's camera from Malice's programs. (Unless there's a channel for the Linux partition to send read and write requests to the partition that owns the USB host controller, in which case you're back to square one unless that partition can somehow detect that the Linux partition has been compromised - which seems likely to be a halting-complete task.)
So, unless there's something I've missed, I stand by my assertion: This is a software and wetware problem, and a fancier MMU is not really the hardware solution. (The sensible hardware solution is a physically-operable killswitch for the camera and microphone which can't be bypassed by software.)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds