Possibly one cybersecurity-related thing you could do is run a headless browser inside this VM, and bridge the network requests to the host network (a little bit like Docker).
Using my open-source BrowserBox^0 project then you could have a "bit more isolated" Browser running on your Android device that would add "VM escape" to any zero-day exploit chain that might be a risk.
This is speculation tho, I don't know if it's actually feasible based on the Android reality right now, but assuming the capabilities that are provided are like a regular headless VM, then it should be. :)
Why do you need VM for isolation? ARM architecture already provides tools for isolation, like MMU and privilege levels. Why do you need another kernel, emulation of hardware devices? It is completely wrong method.
For sure, ARM's MMU and privilege levels are solid for base isolation. But consider the VM for a headless browser as an extra layer of defense, especially in the wild and crazy web threat landscape. Yes, it involves another kernel and some hardware emulation, but modern VMs, particularly with Android's AVF, are designed to be lightweight and efficient.
With AVF, we're looking at tailored isolation, where a VM can be as minimal or as comprehensive as needed. This flexibility means we can create a highly controlled environment for the browser, enhancing security against web-specific exploits. It's about using ARM's strengths and adding a VM where it makes sense for focused, web-centric security. The idea's to mix and match security layers for the best defense, especially with Android's new AVF making VMs more streamlined.
I guess you could say the goal here is to tailor the security approach to the specific risks associated with web browsing, making the system resilient against a broader range of exploits.
The kernel simply has too much code in it and too wide of a boundary to consider a good security boundary. VMs have a much smaller surface by comparison. I don't think reaching for a VM would be necessary if you had a smaller kernel.
How does the video get out? That implies a strong connection to the screen, which has a big attack surface.
This is the classic problem with isolation via virtual machines. To do anything, they have to talk to something, and that's where the security breaches occur.
DRM already uses a trusted execution environment (TEE), which provides more robust isolation than a VM. Thus I doubt needs of video streaming apps are the main motivation.
The DRM TEE on Android needs to be baked in at the factory. If an app brings its own DRM then it's not able to use the TEE. If this enabled apps to use TEE like functionality it'd be good for that use case.
How much of this is closed source?