Virtual machines with KVM on Pixel 6 and Android 13 DP1

Radio firmware doesn't actually matter much in practice because they mostly hang off a non-DMA peripheral bus, and in any case, even if that's too much for your liking, rest assured any actual secure communication device will treat the radio as compromised by design. It comes with the territory of secure encrypted communication; the difference between "compromised radio" and "compromised router" and "malicious upstream ISP" are all effectively zero in terms of design. You use E2E, secure key storage, etc. It's all effectively the same threat model of a spy who can watch at some communication junction.

Don't get me wrong, it'd be nice to have a simple modem you could put Yocto on and then attach to some other thing over a memory interface. But it's really just a dumb set of pins you read and write to; the "meat" of the device security happens outside of it, and long before the data hits it.

Also I think there is some work on reverse engineering the AT commands for some PinePhone modems, which means you can install a Linux distro on the device to manage and talk to the radio. It's not the same as FDA-approved baseband firmware or anything (that wouldn't run Linux), but it's probably as close you can get for now.

There's an urban legend that the baseband processor is an all governing, closed source backdoored bad actor in your phone. This may have been true for 2005 era dumbphones, but in reality your smartphone's radio is attached like a USB device is. In phones made in at least the last 10 years, it doesn't have a privileged position at all. I don't know why that legend keeps on being perpetuated.

There's a lot wrong with hardware openness on mobile devices, but closed bootloaders and radio firmwares are also true on most Linux laptops that can thrive nonetheless.

A note:

> On Qualcomm SoCs, EL2 is occupied by their HypX hypervisor, so KVM is impossible without exploiting HypX. I don't think OEMs are allowed to do much about it, and it seems to be a somewhat integral part of their platform, so removing it would likely be a big undertaking even if OEMs were allowed to do so.

For Chrome OS firmware stack, full EL2 is given to the kernel, the regular way.

For the Windows on Arm64 stack (on currently shipped SoCs), a mechanism, Secure Launch, is provided to escalate from EL1 to EL2. bootmgfw issues a SMC call, the function is the same as the one used to initialise Intel ACM or AMD SKINIT. QHEE intercepts it, does some sanity and integrity checks then remaps memory to load the TCB launcher and jumps to the entry point. This means that if you run Linux on those, you don't have EL2.

For more background on the technical details, I found this presentation describing how KVM works with Arm EL2: https://events.static.linuxfound.org/sites/events/files/slid... (pdf)

Thank you for the elaborate answer, and for your admirable work.

I would actually want that but all the existing implementations are slow, with poor support and none of them provides the smooth experience we can have on a dedicated desktop pc or laptop. Dex is just laughable. Ubuntu touch never took off.

I had a Motorola Atrix (gen1), which I miss dearly. It was amazing to have a full Ubuntu installation along with Android all on one device. I really bought into the ecosystem: had their lapdock, media dock, etc.

And Windows Continuum!

Not sure about this implementation, but most virtualization implementations, including most KVM/libvirtd/QEMU ones, support shared directories.

Have they made Chromecast performance decent yet?

Every time I've used it, there is so much lag that it's unusable for a 2nd screen. Even for non-interactive screen mirroring like letting someone else watch you browse the web or play a game it's jerky and laggy.