By that measure, virtualization is long overdue, but I really can't claim that I'm not surprised.
In English, there is a sentence structure like ‘I ain’t telling nobody’, which means ‘I won’t tell anyone’, but for me it’s difficult to decipher as well. Why it’s not like ‘I’m telling nobody’ or ‘I’m not telling anyone’? Why the double negative — ain’t and nobody — means negative as well.
Same issue is here. I don’t understand whether they were surprised or not. I assume they are not surprised. But the difficulty of the phrasing makes me wonder the meaning behind it.
I think you mean "I can't say I'm surprised" -> this is not at all surprising. But that's just one negative.
Fun facts, Unix name is a joke to Multics, where Multi stands for multi-user, and everyone know what happened soon to Unix single user name indication.
I don't think UNIX was ever meant to be single-user. This interview suggests that's not where the name came from anyway: https://www.linuxjournal.com/article/7035
If you think about it, much of the complexity of Multics come from its multi-user requirement with overly complex access control matrix, multitude of file types including design for multi-user support, etc. Thus the Unix name metaphor or pun is to make it the latter simple by requirement and design. Remember that Unix was started as a skunkwork and even the original PDP-7 that being used originally was donated by other department of AT&T if I remember correctly it was the sound signal processing department [1]. If it is an official project, the multi-user requirement will be there from the start since arguably AT&T is the largest technical company at the time and they will want multi-user from the get-go.
But after some time and considerable success of Unix, the designers probably looks childish due to the naming since they did introduce multi-user at the later stage, and toned down the exact meaning of Unix. What is the opposite of multi, it is uni.
[1] The Strange Birth and Long Life of Unix:
https://spectrum.ieee.org/the-strange-birth-and-long-life-of...
Not sure if this architecture can handle that, nor of it's the best architecture to solve this problem, though.
It's much like how web browsers' incognito/private mode is really useful for web developers and certain kinds of troubleshooting, but those are tertiary uses to the primary consumer use case for which it was originally built: browsing porn without leaving history behind.
Normal apps usually don’t have the opportunity to run there, so this levels the playing field somewhat in terms of security.
And unless there is also attestation or binary encryption involved, I doubt this would give app developers any DRM-like capabilities.
Maybe another OS, if someone does the groundwork on that. Or, fully suspend and move running instances across devices, which I think xen can already do.
1. https://source.android.com/docs/core/virtualization/architec... 2. https://wiki.xenproject.org/wiki/Xen_Project_Software_Overvi...
Ironically the revenge of microkernels, as most cloud workloads run on type 1 hypervisors.
AMD Secure Encrypted Virtualization (SEV)
Bare metal runs a tiny L0 hypervisor making use of hardware support for nested virtualization. In turn, the L0 can run an L1 hypervisor, e.g. KVM or "host" OS, or minimal L1 VMs that are peers to the L1 "host"-guest of L0.
Google pKVM-for-Arm tech talk (2022), hopefully x86 will follow, https://www.youtube.com/watch?v=9npebeVFbFw
In the best case future, this will offer security properties based on a small OSS attack surface, rather than black box TEE firmware.
How much of this is closed source?
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. :)
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.
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.
> On the Pixel 7, the most configuration you'll need to do is similar to Shizuku. You connect to your own phone over wireless adb, configure the maximum container size, and then choose your Linux distribution. It'll download, configure, and then execute the virtual machine.
Not everyone gets to be root, and even for devs there are IT management tools that only allow root for specific use cases, or time boxed.
I haven't seen this personally (not saying it isn't a thing to be clear, just I haven't seen it).
My major issue is that for some reason there are carriers in the US that seem to think a user having control over their own device is something to frown on. I get the potential support and warrently nightmare involved but on the other hand it's not a super easy process that one would do accidentally.
edit: according to this[1], yes, the pKVM functionality that's standard in Android exposes KVM functionality so that you can run VMs on Android.
[1] https://www.xda-developers.com/android-13-dp1-google-pixel-6...
Would graphics acceleration work properly?
> pKVM is built on top of the industry standard Kernel-based Virtual Machine (KVM) in Linux. It means all existing operating systems and workloads that rely on KVM-based virtual machines can work seamlessly on Android devices with pKVM.
What's the current state of the art for Android virtualization? Let's assume we're talking about the newest Pixel and newest Android version. Is there any way to safely run malware or the Facebook app in some sort of air-gapped container and throw it away when you're done?
You are putting too much faith in your VM monitor to keep you safe. There's a lot of attack surface in (for example) QEMU peripherals, and there's plenty of examples of VM escape [1]. CrosVM is probably the only publicly available VMM I'd be willing to trust, and even then I'd be nervous running state-sponsored malware on a machine with important data.
However, most of the exploits you'll find in QEMU are against configurations that are never used in real world virtualization scenarios where guests are untrusted. You can recognize them because hardware not commonly used with untrusted guests does not get a CVE.
For a while, slirp was the remaining major issue because it was used way beyond the original intention. But now it's been tamed and there's also passt, a much higher performance and much more secure implementation of user-mode networking.
This is not true. Even non default configuration of any software or hardware that contains a security vulnerability can get a CVE. It has in the past and will again in the future.
Source: I have assigned over 2000 cves for the kernel.
In case anyone else needs a link: http://blog.vmsplice.net/2021/10/a-new-approach-to-usermode-...
User profiles can be used in this exact way. Guest user if you intend to install+wipe it right away (though this will prove cumbersome eventually due to having to reinstall the app every time, etc). There is a significant isolation benefit to them, though not currently virtualized. With the isolation can come usability issues. Like transferring files from one profile to another.
They can very slow however (slow to load+setup, and switch between, I mean. when you're inside its effectively a separate, fresh, OS install).
Nevermind, only the demo app, not the tutorial, so who knows what its doing.
But you and I both know that this feature was designed for the DMCA-lovin' Hollywood types and the control-freak enterprise IT BOFHs, not for your cool hack.
Let's use their tools of oppression against them! (fist emoji)
Newer markets include cashless (CBDC) payments and digital identity anchored in human biology, demanding more security than legacy content.
> Biometrics: By deploying biometric trusted applets in an isolated virtual machine, developers will have the isolation guarantee, access to more compute power for biometric algorithms, easy updatability regardless of the Trustzone operating system, and a more streamlined deployment.
Fortunately, OSS can enable N-party transaction transparency, we don't have to settle for one-way mirrors and WeChat clones.
If AVF allows running native code, it might actually be cheaper than the current arrangement.
Also, Java "virtual machines" and native virtual machines are two very different things, they shouldn't be equated.
Literally, the title: ‘Virtual Machine as a core Android Primitive’ and the very first sentence: ‘The Android Virtualization Framework (AVF) will be available on upcoming select Android 14 devices.’
I'd love the easy ability to run confidential computing loads with fine grained control over the data it gets access to. You can do this now on the desktop using SGX (etc) but on mobile it's really hard.
As a specific example of this, it'd be great to be able to run Whisper continually and have strong, system level guarantees about what can read the data.
Do you trust any modern OS not to accidently include sensitive information when it generates a crash report for an app and sends it off the some remote server in the background?
Isolation is a useful tool. In an ideal world it can be done perfectly at the OS level, but we don't live in that world.
I think there are usecases like this outside the mobile _phone_ that are interesting. For example on-device learning for edge devices where the device is not under your control.
So in general, just would avoid labeling the quality of other people's takes. You never know who is reading yours
(Putting aside the fact for the moment that most - if not all - trusted computing platforms have some security vulnerabilities. Obviously this is bad, but doesn't preclude their utility)
DRM and remote attestation already use a separate secure environment, so I don't see what would change by adding virtualisation.
There will be a chilling effect because people won't want to upset their Google/Microsoft/Apple/Meta etc overlords by saying or doing the wrong thing, and then get locked out of services they need to exist in society, do their job, spend money, etc.
I'm no fan of the modern dependence on Play Services or Google's attempts to kill adblockers through remote attestation, but none of these technologies are inherently bad. Business devices authenticating to business websites should allow remote attestation to verify that their hardware has not been tempered with just as an extra security measure.
Maybe your government is more evil or incompetent than mine, but bad governments aren't going to he limited by technological concepts like these.
It's like SafetyNet today, you can't run a good amount of apps on unapproved platforms already, even apps that don't handle confidential data.
When I traveled, this is how I was able to spend money without having to call my bank every time I tried to use my card in person.
Confidential computing is cool and useful when you’re the one controlling the VM, but scary when you’re the one blindly running it on your hardware
Hopefully this gets (publicly!) backdoored like SEV, SGX, etc
Important point.
> Hopefully this gets (publicly!) backdoored like SEV, SGX, etc
From my reading this doesn't need to be backdoored, if you have the ability to unlock the bootloader, you are not reliant on googles root of trust to be able to use this feature, you can go ahead and become your own "vendor", by signing your own images, or use your choice of vendor, then relock the bootloader and have the same security guarantees.
I'll admit this only from a cursory glance over the documentation and a vague understanding, happy to be corrected, but seems a lot of the arguments in this thread are about your first point, who has control over the OS.
I'll also add that the EU is being quite proactive in people having control over their own device, and who is their 'choice of vendor' so while I understand concerns people bring up, I'm a bit more optimistic that it can be a more useful tool than not.
