On many Android devices, especially Pixels, devices being 'locked' is not the problem at all. It is that historically Android was built to fundamentally different from mainstream Linux, and it is hard to make mainstream Linux work with your phone's hardware [1]. And the phone hardware providers are notoriously terrible about supporting anything.
Since virtualization abstracts those historic incompatibilities and driver issues away, there's a lot more stability you can expect from there. That is in addition to some other legitimate changes Google is making to make Pixel phones somewhat closer to mainstream Linux.
[1]: PostmarketOS shows that it's very possible to do so on plenty of devices, but just not without a lot of tradeoffs: https://postmarketos.org
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.
While everything you said is true, there's one big problem: even if you isolate the baseband and treat it as hostile, there are some things that it is able to do on its own and no amount of sandboxing can fix it.
By design, a baseband is able to track and report your location in real time without ever involving anything outside its silicon. Most basebands are also hooked directly into the microphone and maybe even camera.
Since all but a handful of phones have the necessary hardware allowing the CPU to disconnect the baseband from the mic/camera, no amount of clever software can stop a compromised baseband from eavesdropping and even with special hardware, unless you're willing to cut power completely, it will always be able to track you.
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.
The radio firmware can be remotely updated, without the OS being involved. EG, by carrier. It has direct access, without OS involvement, to many peripherals.
At that stage, any further discussion (being able to read system ram or not, segregation or not) is moot, for, it's the ultimate in lack of trust.
This is amazing news! I've been wanting this since the Nexus 5X where I built a kernel with KVM and was disappointed to see the "kvm failed to become hypervisor" message in dmesg.
> There's actually a permission for apps to run a native service in a Microdroid VM (system-managed crosvm + Binder vsock), though I haven't gotten it working on DP1. Direct KVM access requires root though.
I bought the Pixel 6 looking for some approximation of openness, so this makes me happy to see. Does anyone know what significance the specific hardware (Google Tensor) has in this?
In the Android 13 bootloader and firmware for Tensor, Google added the ability to expose the EL2 hypervisor privilege level to the kernel for their protected KVM feature (pKVM). Protected VMs seem to be an optional feature, however, so full KVM access is available as far as I can tell.
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.
On Exynos SoCs, the kernel boots in EL1, but Samsung has a security feature called RKP that involves loading code in EL2. This means that it's theoretically possible to hack it up for enabling KVM, but KVM doesn't just work out-of-the-box.
I'm not sure about other SoC vendors, but the most popular one by far (Qualcomm) effectively makes KVM impossible.
> 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.
It's a real shame the number of privilege levels is fixed. This seems anti-turing-completeness. Instead, any VM or hypervisor should be able to emulate an environment that is indistinguishable from the environment it itself is running in. That in turn means that hypervisors must be infinitely nestable, and there must be no way for software to know that is running in an emulated environment (unless the hypervisor above wants to reveal this info).
I get that 'infinitely nestable' is hard to implement in hardware, and it's much easier to design things with a fixed nesting depth/number of privilege levels, but I really don't think it would have been much of a stretch to design the instruction set with traps in the right place to allow software to implement infinite nestability without too much of a performance hit.
> but I really don't think it would have been much of a stretch to design the instruction set with traps in the right place to allow software to implement infinite nestability
Nested virtualisation is available for server cores starting from Neoverse V1 onwards, but not for Cortex…
(Also, EL0 could be used as a problem state for this, but some complexities associated to that make it awkward. Unlike POWER (which does have KVM-PR), VBAR doesn’t link to a physical address)
Does W11 in a VM mean you could effectively dock your phone into a monitor and use it as a proper PC with shared filesystem access to all your Android stuff?
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.
Yeah, everyone is already familiar with Windows. And to plug your phone in and have access to the same Pictures, Documents, Videos etc folders from the android filesystem sounds like a dream. Sort of like how Parallels automatically syncs those folders in a Windows VM on a Mac.
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.
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.
There have also been a few projects to boot the ARM version of Windows on various Android phones, no VM involved. None of them really have good enough driver support to use as a daily driver though.
Looks like the meat of this is just 4 photos, 2 videos, 3 tweets. Unless you want to dig through the rest of the conversation, in which case you could click through to the Twitter thread linked originally.
