Android 15's Virtual Machine Mandate is Aimed at Improving Security (androidauthority.com)
- Reference: 0175451091
- News link: https://it.slashdot.org/story/24/11/11/1748241/android-15s-virtual-machine-mandate-is-aimed-at-improving-security
- Source link: https://www.androidauthority.com/android-15-virtual-machine-mandate-3498428/
AVF, introduced with Android 13, creates isolated environments for security-sensitive operations including code compilation and DRM applications. The framework also enables full operating system virtualization, with Google demonstrating Chrome OS running in a virtual machine on Android devices.
[1] https://www.androidauthority.com/android-15-virtual-machine-mandate-3498428/
Probably for the DRM (Score:2)
The summary mentions DRM as just another feature, but I'd guess it's the motivating one.
Rooting, too (Score:2)
Wouldn't be surprised if AVF neutered root access as well. To be fair, this probably *is* more secure - I appreciate the ability for Aegis to extract the private keys from Authy to facilitate migrating, but readily admit that it's pretty horrifying in an adjacent context. Running each app in its own isolated VM would likely prevent the nefarious version of this, but also the legitimate one.
To your point, I'm sure Netflix and Disney and HBO are thrilled to have a more effective defense against the Widevine f
Re: (Score:2)
> Curious... how does one accept that Google encourages and supports syncing those private keys (the TOTP keys, as well as passkeys), which involved them extracting them, uploading them to their servers, long term storage on their servers, and sharing them with other devices (hopefully your own), while accepting and defending the practice of not allowing the end user to extract those same private keys for their own personal backup or so they can manually add them to other devices to which they have physical access?
Oh, I don't...it's why I run /e/OS, and the reason I was moving from Authy to Aegis was because Authy started getting touchy about running on a rooted phone after their hack...I'm definitely a fan of keeping my keys where only I can access them for the very reasons you specify.
The best answer I can give to your question, though, is that the fundamental tenet behind being all-in on the Google ecosystem is the idea that Google does better data and device administration than the user...and for many, many peopl
Re: (Score:2)
But Aegis can only do it with root. Otherwise the existing jails are sufficient to prevent such things.
Re: (Score:2)
> Wouldn't be surprised if AVF neutered root access as well.
I can't think of any way in which the AVF move will have an effect on rooting (and I'm the TL of the Android HW-backed security team, so my knowledge is pretty deep here). The AVF move is more about enabling compartmentalization of stuff that is currently all lumped together in TrustZone, as well as potentially enabling new security features which are currently too big/complex to be implemented in TrustZone.
For one example, I'd like to see the user authentication screen moved out of Android and into somet
Re: (Score:2)
Passkeys are probably the biggest reason. They like better DRM, but with all the older devices and PCs they have to support for the next decade or so it will take a long time to become relevant.
Re: (Score:2)
When security weaponizes the device against the owner, it isn't a security system, but is in fact malware and that is exactly what this will be.
Re:Probably for the DRM (Score:5, Informative)
> When security weaponizes the device against the owner, it isn't a security system, but is in fact malware and that is exactly what this will be.
In what way do you think this weaponizes security against the owner? Note that if you have questions, I'm the TL of the relevant Android team and happy to answer them. This work is all being done directly in the Android Open Source Project, so there aren't any secrets. It's all there in the publicly-accessible code.
Re: (Score:2)
> The summary mentions DRM as just another feature, but I'd guess it's the motivating one.
It's relevant, but probably not in the way you think. The Android security team doesn't care about DRM. However, existing DRM strategies have in the past harmed platform security, and one of the motivations for using VMs is to compartmentalize DRM to eliminate the risk.
Currently, Android video DRM is implemented in ARM TrustZone on ARM devices (and all Android devices are ARM-based, to a first approximation). Several critical security features are also in TrustZone, notably the cryptographic services comp
Sure, we believe (Score:2)
Time to leave Android. It did well first 5 years or so. Now users control is taken away bit by bit. Security, yup, of course. Just mention that without explaining how and everyone believes. It is IMHO to enforce watching ads or hiding some activities a user might want disabled.
Re: (Score:2)
> Time to leave Android. It did well first 5 years or so. Now users control is taken away bit by bit.
How does AVF take away the user's control?
Re: (Score:2)
AFAICS this is basically just a standardization on a Google implementation of a hypervisor, the Android Compatibility requirements used to leave it up to the device manufacturers how to implement isolation for keystore encryption/decryption algorithms.
I assume this is mostly because of passkeys, with synced passkeys Google wants more control. Forcing their own hypervisor is a lower cost option than forcing a secure processor and also useful for DRM.
Re: (Score:2)
That's not necessarily how it "should be done". It depends on your security and performance constraints. Besides, while you're of course not directly exposing the host's kernel ABI to guests executing in VMs, in order to get a nice integration for all your possible workloads you would still need to expose host interfaces to the guest somehow, meaning guests wouldn't be completely isolated anyways.
Re: (Score:2)
> Besides, while you're of course not directly exposing the host's kernel ABI to guests executing in VMs, in order to get a nice integration for all your possible workloads you would still need to expose host interfaces to the guest somehow, meaning guests wouldn't be completely isolated anyways.
I've never looked into the details, but what knowledgeable people I trust tell me is that with pKVM the guests are completely isolated from the host and from one another (and the host has no access to the guests either), with a single exception: There is a way for host/guests to communicate with one another by passing messages. So as long as each VM (including the host) is careful to avoid vulnerabilities in their message parsing and processing code, a compromise in one cannot leak into others -- though of