Consider support for Android VMs

[andrewdavidwong]

Over the years, many Qubes users on the mailing lists have expressed the desire to be able to run some kind of Android VM (e.g., HVM) under Qubes OS.

[JohnnyCalavera]

Did someone try to create an android-x86 VM on qubes? I was planning on doing it myself in the near future. (by the way: the stable Marshmallow release is out now)

[grote]

I tried running RemixOS, but without success. There might be a general problem of running Android as a guest in a Xen hypervisor.

[Jeeppler]

@andrewdavidwong can you reference to those mailing list entries?

[andrewdavidwong]

@Jeeppler: This is based on my memory of the mailing lists over the years, so I don't have an exhaustive list. However, here are some examples:

• https://groups.google.com/d/topic/qubes-users/vNTiiulU5n4/discussion
• https://groups.google.com/d/msg/qubes-users/l2bcrfJpF4s/4kUxHqCZAQAJ

[Jeeppler]

According to the posts, people want to run Android x86 to do application development.

However, it seems the Android emulator uses the CPU virtualization extension. The problem could also be solved by using nested virtualization on Xen.

[andrewdavidwong]

Cross-linking new discussion thread:

https://groups.google.com/d/topic/qubes-users/frK8xaBh9pI/discussion

[entr0py]

@grote I have not had any issues running RemixOS under Qubes. But it suffers from the same Android-x86 mouse issue mentioned in the thread that Andrew just linked.

Qubes is actually a convenient platform for running Android emulators because most of them don't allow static IP addresses. Qubes' mini-DHCP server works just fine.

[grote]

@3n7r0p1 which version did you use? Could you send me the link to the download?

Please also let me know if you find a solution for the mouse issue.

[entr0py]

I used an older version of RemixOS so I checked again with the latest release and it also installs and boots fine.

version: 3.0.206, 64-bit
filename: Remix_OS_for_PC_Android_M_64bit_B2016101201.zip
download: http://www.jide.com/remixos-for-pc#downloadNow
https://www.fosshub.com/Remix-OS.html

when booting iso, add INSTALL=1 to kernel parameters
create partition, gpt: no, efi: no
if boot hangs, add vga=ask to kernel parameters (may need debug mode on)
allow 10-15 mins for first boot, 10-15 mins for desktop after setup

Confirmed mouse behavior hasn't changed. Not all functionality can be replicated from keyboard. Unusable without mouse fix.

IMO, RemixOS is more resource-heavy than Android-x86 (especially graphics).
I've Googled the heck out of the mouse issue. Don't have the expertise to take it any further. :(

[Wikinaut]

👍 yes, please

[micahflee]

I just tried android-x86 in an HVM, and it actually works great (the only change I had to do was increase the RAM -- I'm using 4GB, but it probably will work with less). It doesn't have the same mouse issues as RemixOS (which, as of today, is a discontinued project).

I downloaded an Android 4.4.4 iso from https://sourceforge.net/projects/android-x86/ -- but the more I look into it, it appears there are later versions of android-x86 available, including 7.1: http://www.android-x86.org/releases/releasenote-7-1-rc1

[micahflee]

It would be cool to make an Android template. I'm not quite sure how the partitioning could work so that android-x86 AppVMs could have private images though.

[micahflee]

Update: I tried installing android-x86 7.1 in an HVM, and it doesn't work nearly as well as 4.4.4. I could boot in live mode, but I had the same mouse issues that exist in RemixOS, and when I install to the hard disk and try booting, it never finishes.

[nm8800]

@micahflee How did you get an AndroidVM to work in Qubes? Currently trying to figure out how to use the Android-x86 vm to do the same.

[aseralis]

I push the topic gently upwards, an android HVM in qubes would be great! Unfortunately it's very painful to get Android x86 running, but I'm going to test a bit by myself and share results.

[kuzega]

So hows going with android vm ?

My testing results on qubes r4.0-current-testing are that none of android works so far.
Tested iso images : remixOS, android x86 latest cyanogenmod 7.1 release1 and normal 7.1r1, 4.4r5, phoenixOS.
None of them detect the hard drive.
So another test I installed centos7minimal then andro x86 latest cyanogenmod in rpm package so it added grub entry, it does not boot
Most of the tests showed familiar boot screen but did not run, VM killed itself.

But i remember it was working on qubes 3.2, cant remember what android did i run but probably it was remixOS, when i was testing this like a year ago or so. It was install-able but did not boot from installation, had to use iso and all the changes were gone. The performance was really choppy and i gave up, that probably was because of SLAT feature missing on previous laptop.

PS: was not editing grub entries at all, only tested different VESA modes when available

Hint: try to test preinstalled android VM images and just put them in /var/lib/qubes . Personally i couldnt get this method to work, first have to convert given preinstalled images to qcow RAW format

[tonsimple]

@micahflee
Sorry for nagging, but could you please kindly step-by-step creation of android HVMs under Qubes R3.2 for the less talented of us?

can't seem to make it boot/install (tried Android 4.4.4 and later)

[tschakram]

Hello,
any solution to get a android hvm running on Qubes 4 ? Booting a live iso worked for all Versions of Androidx86,RemixOS and CM. But installtion failed because of the error "No hard drive avalible". Possible to prepare the hvm drive before installing?
thanks

[ptitdoc]

Hello,

Here are my limited success to deal with an Android HVM in Qubes R4:
1/ Download Android x86 ISO (tested with android-x86-7.1-r2.iso)
2/ Create an HVM
3/ Give at least 4000MB of RAM to the HVM and disable memory balancing (testing with 2000MB caused the VM to crash during startup)
4/ In the QubesVM advanced settings, select "Boot qubes from CDROM" and use "from file in Qubes" to select the ISO you downloaded
5/ When the VM boots, select Advanced options > Live CD VESA mode - No GPU hardware acceleration. Other options are working but this is the most stable I found. (Press space when android boots up)

Here are the issues I'm also facing:

• The mouse works strangely because of QubesOS libvirt settings. For this reason, it is needed to use drag and drop all the time inside the Android window in order to use the mouse. To improve this it is possible to edit in dom0 /usr/share/qubes/templates/libvirt/xen.xml and to change the line:
  <input type="tablet" bus="usb" />
  to
  <input type="mouse" bus="usb" />
• It is still not possible to install the android VM using recent Android version because the hard disk drive is not detected. Apparently Android does not supports disks presented as Xen block devices. Maybe the problem is similar to Default emulated disk in Qubes 4.0 HVM is not supported by Windows 7 installer #3068.

[airelemental]

Someone got it installed: https://groups.google.com/forum/#!topic/qubes-users/JGDqzuf1dS0

[ptitdoc]

Thanks for the pointer.

By the way, people are talking about problems with networking, but networking works out of the box in my case.

[mat-rex]

ptitdoc, what version of android did you try? I think I shot myself in the foot with 7.1.2, as might have a bug with ethernet and dhcp.

I did the following 2 changes:

1. Changed 1 line in "init" inside initrd
   from:
   for device in ${ROOT:-/dev/[hmnsv][dmrv][0-9a-z]}; do
   to:
   for device in ${ROOT:-/dev/[hmnsvx][dmrv][0-9a-z]}; do
   That allows the XEN hard drive to be used at initialization, once the kernel has the driver.
   I would appreciate if this change would go into the repo there if you (enyone) are an android-x86 developer.

2. I configured the kernel

[mat-rex]

A bit of a time passed, and on the sideline I have a config with which the mouse is a mouse, but you have two pointers. If you change the cursor to large, you can get used to it. Network configuration is stil manual and a pain.

Once you build android with that you get a CD (The best if you use the android common build environment... it took me days to get a build on 16G with qubes... but can be done). If that is too much, I can provide you the CD somehow (but why would you trust someone to provide you a CD ... but if in that VM, you have nothing to loose, you do not risk too much :-) ).

Create a new HVM. Boot a recent linux CD/DVD/thumbdrive (I was using the openly available, but unannounced knoppix 8,2).

boot your VM from the linux CD. Create an EXT2 partition to boot (50 or 500 megs? do not remember). install the bootloader from the cd.

Shutdown linux. Boot android.

Install Android to the free space, creating a new partition "ext4". reboot.

Boot linux again. Mount both partitions, copy kernel and inititial ramdisk, into the boot directory. Do NOT use the same name as what the android-x86 install created on the EXT4 partition.

google:
andoid-x86 boot grub

update grub/menu.lst according to the instructions found, modify directory name.

reboot end enjoy if you can without a network.

If you need networking, google android-x86 static ip.Use the IP quebes allocated your vm. Or find instructions on how to setup dhcp from the command line - I did not figure that. I have no clue why it does not autodetect.

If some succeeds, please post detailed instructions and CD. I posted this without the actual system at hand, so steps are as I remember from top of my head from many weeks ago.

Please post if you fail as well, when I'll check here (maybe soon, maybe a few month) if there are failure reports I'll try to post a detailed instructions with the system at hand.

[mat-rex]

The behaviour of the mouse in qubes 4 appears to come from:

/usr/share/qubes/templates/libvirt/xen.xml

Replace the word " tablet " with " mouse ", and mouse will become an emulated mouse in the HVMs. You get two mouse pointers - but if you change the size (I set it to max of 48) of your desktop mouse (Dom0 - system tools - settings manager - Mouse and touchpad - Theme) so the two can be distinguished, it is usable.

This allowed me to run a BSD gui environment in a HWM. I'll see how this changes things for Android.

[bi0shacker001]

Not sure if this is still an issue, but there are instructions on how to set up templates which use sway with waydroid for an android vm. This'll probably get easier as qubes moves to wayland, maybe a waydroid session template (https://docs.waydro.id/faq/setting-up-waydroid-only-sessions) after the migration?

[maltfield]

I did, in fact, get waydroid working inside an Ubuntu HVM. This is from my personal notes from a few years ago

sudo apt-get install weston curl wget ca-certificates
wget https://repo.waydro.id/waydroid.gpg

# verify key fingerprint
gpg waydroid.gpg

mv waydroid.gpg /usr/share/keyrings/
echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ bookworm main" | tee /etc/apt/sources.list.d/waydroid.list
apt-get update
apt-get install waydroid

# open a wayland UI
weston

# in the wayland Window, open a terminal and in *that* terminal, type
sudo waydroid init
sudo systemctl restart waydroid-container
waydroid session start # make sure this is *not* root

# then in another terminal
waydroid app install F-Droid.apk

# prevent the screen from rotating https://github.com/waydroid/waydroid/issues/70
waydroid prop set persist.waydroid.multi_windows true

waydroid show-full-ui

But it's buggy as hell and, most importantly, waydroid contributors said that waydroid shouldn't be used for anything sensitive since it's horribly insecure.

I've been monitoring this thread specifically because I was hoping to find a way to run an Android VM in Qubes that's actually secure (eg for extremely compartimentalized banking apps locked inside Qubes, not on my everyday personal phone)

The devs ITT above pointed me to BlissOS, but I didn't look into using it in Qubes yet

• https://blissos.org/

[bi0shacker001]

I did, in fact, get waydroid working inside an Ubuntu HVM. This is from my personal notes from a few years ago

# open a wayland UI
weston

# in the wayland Window, open a terminal and in *that* terminal, type
sudo waydroid init
sudo systemctl restart waydroid-container
waydroid session start # make sure this is *not* root

# then in another terminal
waydroid app install F-Droid.apk

# prevent the screen from rotating https://github.com/waydroid/waydroid/issues/70
waydroid prop set persist.waydroid.multi_windows true

waydroid show-full-ui

But it's buggy as hell and, most importantly, waydroid contributors said that waydroid shouldn't be used for anything sensitive since it's horribly insecure.

I've been monitoring this thread specifically because I was hoping to find a way to run an Android VM in Qubes that's actually secure (eg for extremely compartimentalized banking apps locked inside Qubes, not on my everyday personal phone)

(as a note, that prop doesn't stop the screen from rotating, it enables "seamless" mode. Apps will still try to rotate if you have a device with an accelerometer, it'll just break them when they do. You can run "wm set-fix-to-user-rotation disabled" to forcibly disable autorotate)

The security issues with waydroid are the same ones we deal with in other linux apps. They're ostensibly worse on qubes, as we give the user account passwordless root. That said, I'd say it's no more insecure than running any other code in a qube, as all applications could grab root immediately and effortlessly with sudo, if they wanted to. It'd still be contained by the qube itself.

[maltfield]

The security issues with waydroid are the same ones we deal with in other linux apps

My biggest concern in these Android Emualtors is the supply chain and the risk of obtaining inauthentic code that's been maliciously modified.

I'm not worried about my banking app taking over the host AndroidVM that was created just for the purpose of running this one "trusted" app.

I am worried about downloading a malicious copy of an Android Emulator that has spyware that can see what I'm doing in my banking app or, worse, steal my credentials or preform actions to my banking accounts on my behalf.

Most Android ROMs don't even sign their releases (LOS refused to sign their releases with PGP), and their build chains often include fetching unsigned code (anything with pip is a red flag, for example) so they're a target for watering hole attacks.

[bi0shacker001]

The security issues with waydroid are the same ones we deal with in other linux apps

My biggest concern in these Android Emualtors is the supply chain and the risk of obtaining inauthentic code that's been maliciously modified.

I'm not worried about my banking app taking over the host AndroidVM that was created just for the purpose of running this one "trusted" app.

I am worried about downloading a malicious copy of an Android Emulator that has spyware that can see what I'm doing in my banking app or, worse, steal my credentials or preform actions to my banking accounts on my behalf.

Most Android ROMs don't even sign their releases (LOS refused to sign their releases with PGP), and their build chains often include fetching unsigned code (anything with pip is a red flag, for example) so they're vulnerable to watering hole attacks.

Wouldn't we have that issue regardless of what solution we go with? Short of building android locally on our own device (which we CAN do, and waydroid will run the image), there aren't any solutions which require signed images, and nowhere really releases them. Unless you're referring to trusting the Qubes project to verify the android they ship in a template.

Android doesn't really run natively, it's already in a simulated environment. The only difference between Waydroid, Anbox, Android-x86, and my phone, is what interface layer everything's being virtualized in, and you'd need to pick one regardless.

[maltfield]

Unless you're referring to trusting the Qubes project to verify the android they ship in a template.

I think that would be the best-case for the UX. I would love for Qubes to ship with an "Android Template" along-side the "Fedora Template" and "Debian Template" and "Whonix Template"

As more-and-more identity providers go with Phone-only apps (I'm looking at banking apps and also the EU's eID legislation that is targeting making eID roll-out mandatory in EU Member States in 2026), I think this will be very important for many users -- being able to lock their banking and eID private keys inside their Qubes laptop instead of exposing it to their phones that are secured with shitty passwords (tapped-out in public dozens of times per day) and are easy to physically break & loose.

Short of building android locally on our own device (which we CAN do, and waydroid will run the image)

Do you have a guide to do this, but which focuses on security -- so we can actually verify the cryptographic signature of all the sourcecode (and all dependencies) that's downloaded before building?

[DemiMarie]

Unless you're referring to trusting the Qubes project to verify the android they ship in a template.

I think that would be the best-case for the UX. I would love for Qubes to ship with an "Android Template" along-side the "Fedora Template" and "Debian Template" and "Whonix Template"

As more-and-more identity providers go with Phone-only apps (I'm looking at banking apps and also the EU's eID legislation that is targeting making eID roll-out mandatory in EU Member States in 2026), I think this will be very important for many users -- being able to lock their banking and eID private keys inside their Qubes laptop instead of exposing it to their phones that are secured with shitty passwords (tapped-out in public dozens of times per day) and are easy to physically break & loose.

On at least Pixels, eID is in part handled by dedicated code running in the secure element chip.

[bi0shacker001]

Unless you're referring to trusting the Qubes project to verify the android they ship in a template.

I think that would be the best-case for the UX. I would love for Qubes to ship with an "Android Template" along-side the "Fedora Template" and "Debian Template" and "Whonix Template"

As more-and-more identity providers go with Phone-only apps (I'm looking at banking apps and also the EU's eID legislation that is targeting making eID roll-out mandatory in EU Member States in 2026), I think this will be very important for many users -- being able to lock their banking and eID private keys inside their Qubes laptop instead of exposing it to their phones that are secured with shitty passwords (tapped-out in public dozens of times per day) and are easy to physically break & loose.

If those are specifically your use cases, most secure android apps are reliant on google Safetynet, which we can neither pass nor spoof on pc. Heck, the days of phones spoofing that are long since over.

Short of building android locally on our own device (which we CAN do, and waydroid will run the image)

Do you have a guide to do this, but which focuses on security -- so we can actually verify the cryptographic signature of all the sourcecode (and all dependencies) that's downloaded before building?

Unfortunately, no. That's not something I've ever worried about when building android roms (i'm not overly concerned with a hostile party finding out how bad I am at fruit ninja, for instance, That's what I use waydroid for, gaming and entertainment)

[ypid]

@maltfield Instead of this:

sudo apt-get install weston curl wget ca-certificates
wget https://repo.waydro.id/waydroid.gpg

# verify key fingerprint
gpg waydroid.gpg

mv waydroid.gpg /usr/share/keyrings/
echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ bookworm main" | tee /etc/apt/sources.list.d/waydroid.list
apt-get update
apt-get install waydroid

You could use extrepo like that:

sudo apt-get install weston ca-certificates extrepo
extrepo enable waydroid
apt-get update
apt-get install waydroid

Ref: https://salsa.debian.org/extrepo-team/extrepo-data/-/blob/master/repos/debian/waydroid.yaml?ref_type=heads

[thestinger]

Waydroid is based on an insecure fork of Android 11 and has most of the security model disabled. It doesn't have app sandboxing intact and doesn't protect the kernel from apps as Android does. It doesn't have SELinux support which is a major part of the Android application sandbox and the overall security model/approach including kernel attack surface reduction. Android depends on SELinux for the basic privacy and security properties to be intact. The main issue is lack of ongoing maintenance and security patches. Only Android 14 gets full security support, but they could at least be shipping the monthly security backports of High/Critical severity vulnerabilities for Android 11 and using AOSP instead of LineageOS.

[apparatius]

Waydroid is based on an insecure fork of Android 11 and has most of the security model disabled. It doesn't have app sandboxing intact and doesn't protect the kernel from apps as Android does. It doesn't have SELinux support which is a major part of the Android application sandbox and the overall security model/approach including kernel attack surface reduction. Android depends on SELinux for the basic privacy and security properties to be intact.

I don't think this will matter much for the default use case as AppVM in Qubes OS with only a single app per AppVM and not using multiple apps in the same AppVM.

The main issue is lack of ongoing maintenance and security patches. Only Android 14 gets full security support, but they could at least be shipping the monthly security backports of High/Critical severity vulnerabilities for Android 11 and using AOSP instead of LineageOS.

This one is an issue for sure.

[thestinger]

It means that a compromise in normally heavily sandboxed OS components is often going to be a compromise of the whole OS including the app. You may not care about the OS being secure from the app if the app sandbox is a VM but you should still care about the OS security. Being on Android 11 is bad enough due to years of missing Low/Moderate severity patches and security improvements but not having the monthly backports of High/Critical severity patches delivered in practice is much worse.

[apparatius]

It means that a compromise in normally heavily sandboxed OS components is often going to be a compromise of the whole OS including the app.

Maybe you're right. I'm not knowledgeable in how android works so I can only guess some things.
Correct me if I'm wrong in guessing this situation:

I have only WhatsApp installed in android.
I receive the image in WhatsApp and open it in WhatsApp.
Android will open the image using some internal image viewing android component (or a WhatsApp component that is separately sandboxed from the other WhatsApp components).
The image is malicious and can compromise the image viewing component but not the WhatsApp itself or other components.
So if the image viewing android component is properly sandboxed then it'll only have access to this image viewing component data and won't be able to easily access valuable WhatsApp data.

[thestinger]

If it's opened in another app or handled with OS media handling, sure, that's how it works. WhatsApp likely handles a lot of the media handling with in-process libraries and it's up to them to do it in an isolatedProcess which they probably don't currently do even though it's very easy. None of the OS sandboxing including isolatedProcess is going to work properly without SELinux. SELinux is not an additional layer but rather a huge part of the basic privacy/security model in Android. It's used much differently from how desktop OSes use it.

[DemiMarie]

even though it's very easy

Is it? Using the IsolatedProcess API might well be easy, but replacing code that runs in-process with an IPC call is not generally easy. Is there something specific about Android that makes it possible to wrap a general media decoding API this way? If so, would it be better for this to be done by Android automatically, rather than each app writer having to do this manually?

[thestinger]

It's easy because it's all abstracted and uses the same API for communicating as a non-isolatedProcess service which are heavily used by apps already. Developers already have to deal with moving things to run in the background and this doesn't change much about it. The main portion of the app runs in a sandbox too and it's not that much different.

[bi0shacker001]

Waydroid is based on an insecure fork of Android 11 and has most of the security model disabled. It doesn't have app sandboxing intact and doesn't protect the kernel from apps as Android does. It doesn't have SELinux support which is a major part of the Android application sandbox and the overall security model/approach including kernel attack surface reduction. Android depends on SELinux for the basic privacy and security properties to be intact. The main issue is lack of ongoing maintenance and security patches. Only Android 14 gets full security support, but they could at least be shipping the monthly security backports of High/Critical severity vulnerabilities for Android 11 and using AOSP instead of LineageOS.

Just as a note: waydroid uses lineageos-based images, which DO receive security updates, and the waydroid updater does receive weekly update images

[thestinger]

Just as a note: waydroid uses lineageos-based images, which DO receive security updates, and the waydroid updater does receive weekly update images

Android 11 support ended after February. Prior to that, Android 11 only received backports of the High/Critical severity vulnerabilities and only the subset deemed to be part of the standard Android security patches. It doesn't include the Low/Moderate severity patches including most privacy fixes, etc. LineageOS only provides a subset of that subset of standard security patches particularly since they make changes incompatible with security features which would be considered security vulnerabilities.

Android doesn't have an actively developed LTS branch for 12, 13 and 14 for use as a mobile OS but rather monthly security backports vendors are meant to apply to their forks. They stopped backporting most Moderate and Low severity patches and stopped assigning them a CVE. If you want all the patches, you need the April monthly release of Android 14 QPR2. For a while, they were listing all of the Low and Moderate severity AOSP patches as part of the Pixel bulletins but since they apply to all devices rather than only Pixels that was weird and they stopped listing them there so they aren't publicly listed beyond the commits now.

Waydroid loses not just a set of assorted security features like LineageOS but rather most of the userspace security model through having SELinux disabled. That includes not just the app sandbox but sandboxing throughout the OS and kernel attack surface reduction. It's not just most of the app sandbox but how media handling, HALs and everything else gets sandboxed within the OS. In the Android 4 and Android 5 era, it was an additional layer of security but it gradually became the main way low-level privacy and security controls are implemented including doing userspace-based enforcement of access to services based on SELinux. For example, without SELinux, any app can connect to the update_engine service since that kind of low-level IPC is controlled via userspace. LineageOS disables downgrade protection, so that's quite noteworthy.

In terms of kernel attack surface reduction, SELinux is how Android restricts access to eBPF to only bpfloader which only netd can use, how it restricts access to io_uring to fastbootd/snapuserd, how it does ioctl command filtering, etc. Additionally, a lot of the kernel options that are enabled by regular distributions including user namespaces, etc. are not allowed by Android and open up major new attack surfaces.

Also, the whole issue of building and distributing updates insecurely without proper signing and downgrade protection.

[DemiMarie]

How useful will Android VMs be in practice? So far, I have seen two uses:

1. As a replacement for the Android emulator, which doesn’t work on Qubes OS due to Xen not having nested virtualization support.
2. To run third-party (presumably proprietary) applications.

It might be possible to replace the Android emulator for development, though without the integrations that the Android emulator has. However, I am seriously unsure if it will be possible to use Android VMs to run third-party apps, mostly because Qubes OS only supports x86 whereas third-party apps will be compiled for Arm. Yes, Android apps are mostly written in JVM languages, but the NDK exists and real apps do use it. Also, any app that relies on hardware security features (like attestation, StrongBox, or Protected Confirmation) will find them unavailble.

[bi0shacker001]

How useful will Android VMs be in practice? So far, I have seen two uses:

1. As a replacement for the Android emulator, which doesn’t work on Qubes OS due to Xen not having nested virtualization support.

2. To run third-party (presumably proprietary) applications.

It might be possible to replace the Android emulator for development, though without the integrations that the Android emulator has. However, I am seriously unsure if it will be possible to use Android VMs to run third-party apps, mostly because Qubes OS only supports x86 whereas third-party apps will be compiled for Arm. Yes, Android apps are mostly written in JVM languages, but the NDK exists and real apps do use it. Also, any app that relies on hardware security features (like attestation, StrongBox, or Protected Confirmation) will find them unavailble.

Houdini and libndk are both extremely performant libraries for arm to x86 translation, so this isn't much of an issue in practice

[tonsimple]

How useful will Android VMs be in practice? So far, I have seen two uses:

1. As a replacement for the Android emulator, which doesn’t work on Qubes OS due to Xen not having nested virtualization support.
2. To run third-party (presumably proprietary) applications.

It might be possible to replace the Android emulator for development, though without the integrations that the Android emulator has. However, I am seriously unsure if it will be possible to use Android VMs to run third-party apps, mostly because Qubes OS only supports x86 whereas third-party apps will be compiled for Arm. Yes, Android apps are mostly written in JVM languages, but the NDK exists and real apps do use it. Also, any app that relies on hardware security features (like attestation, StrongBox, or Protected Confirmation) will find them unavailble.

I kind of think it would be actually pretty useful given a lot of "fancier" messengers out there are mobile-first nowadays, and quite a bit of general purpose computer stuff has better UX on mobile

I think loss of hardware-backed security features is mostly acceptable here, worst case scenario a "QubesDroid" would be as safe as other qubes VM which is reasonably secure (users would just have to update their posture accordingly)

It would certainly be a niche thing (a niche thing I like and desire hard enough to be subscribed to this discussion on-and-off from seemingly its very beginning) but I do think it will find "useful usecases" among Qubes users.

[thestinger]

It's possible to make a software-emulated implementation of the hardware security features where within the context of the VM they're enforced despite not having actual hardware backing outside of it.

[DemiMarie]

That is very much true. To use a trivial example, “The OS can only boot from this disk image, which it doesn’t have write access to,” is a valid verified boot implementation! It isn’t interesting on real hardware because it doesn’t allow updates, but in Qubes OS updates are handled out of band. Similarly, a separate VM running cryptographic software counts as a TEE where Android is concerned.

@thestinger: How bad would it be to allow all third-party applications (untrusted_app and isolated_app IIUC) the ability to make memory executable? The reason I ask is that apps users want to run will likely have native code compiled for Arm, and this code must be emulated. The emulation will likely make use of a JIT for performance reasons.

Houdini and libndk are both extremely performant libraries for arm to x86 translation, so this isn't much of an issue in practice

The only information I can find about houdini is that it is a closed-source interpreter, which I would not consider performant. qemu-user would likely be much faster if NDK support was added.

[thestinger]

That is very much true. To use a trivial example, “The OS can only boot from this disk image, which it doesn’t have write access to,” is a valid verified boot implementation! It isn’t interesting on real hardware because it doesn’t allow updates, but in Qubes OS updates are handled out of band. Similarly, a separate VM running cryptographic software counts as a TEE where Android is concerned.

In a sense, yeah, although it would need a different attestation root and it's not clear if it should really pretend that it's hardware backed but that might be required for app compatibility.

@thestinger: How bad would it be to allow all third-party applications (untrusted_app and isolated_app IIUC) the ability to make memory executable? The reason I ask is that apps users want to run will likely have native code compiled for Arm, and this code must be emulated. The emulation will likely make use of a JIT for performance reasons.

They can already normally do that but the JIT would presumably be external to the VM if not using an x86_64 Android OS. It would be too much work to make it possible to run arm64 apps on an x86_64 OS.

Houdini and libndk are both extremely performant libraries for arm to x86 translation, so this isn't much of an issue in practice

The only information I can find about houdini is that it is a closed-source interpreter, which I would not consider performant. qemu-user would likely be much faster if NDK support was added.

Wouldn't this just be done externally? Modifying the OS to have multiple architectures complicates things a lot. A lot of apps do run on x86 since the developers test in the x86 emulator but not all.

[DemiMarie]

That is very much true. To use a trivial example, “The OS can only boot from this disk image, which it doesn’t have write access to,” is a valid verified boot implementation! It isn’t interesting on real hardware because it doesn’t allow updates, but in Qubes OS updates are handled out of band. Similarly, a separate VM running cryptographic software counts as a TEE where Android is concerned.

In a sense, yeah, although it would need a different attestation root and it's not clear if it should really pretend that it's hardware backed but that might be required for app compatibility.

@thestinger: How bad would it be to allow all third-party applications (untrusted_app and isolated_app IIUC) the ability to make memory executable? The reason I ask is that apps users want to run will likely have native code compiled for Arm, and this code must be emulated. The emulation will likely make use of a JIT for performance reasons.

They can already normally do that but the JIT would presumably be external to the VM if not using an x86_64 Android OS.

QEMU full system emulation is far too slow and is also completely unsupported security-wise. I don’t consider it a feasible option except for testing or demonstration uses.

It would be too much work to make it possible to run arm64 apps on an x86_64 OS.

android-x86 and Waydroid already support it using the aforementioned interpreter.

Houdini and libndk are both extremely performant libraries for arm to x86 translation, so this isn't much of an issue in practice

The only information I can find about houdini is that it is a closed-source interpreter, which I would not consider performant. qemu-user would likely be much faster if NDK support was added.

Wouldn't this just be done externally? Modifying the OS to have multiple architectures complicates things a lot. A lot of apps do run on x86 since the developers test in the x86 emulator but not all.

Google’s emulator images come with this support (source: https://chgans.design.blog/2021/05/23/adding-arm-native-bridge-to-the-aosp11-x86-emulator/). The question is how to provide an open source implementation that can be used here.

[unman]

On Sat, Mar 30, 2024 at 10:08:00AM -0700, Daniel Micay wrote: [quote] Waydroid is based on an insecure fork of Android 11 and has most of the security model disabled. It doesn't have app sandboxing intact and doesn't protect the kernel from apps as Android does. It doesn't have SELinux support which is a major part of the Android application sandbox and the overall security model/approach including kernel attack surface reduction. Android depends on SELinux for the basic privacy and security properties to be intact. The main issue is lack of ongoing maintenance and security patches. Only Android 14 gets full security support, but they could at least be shipping the monthly security backports of High/Critical severity vulnerabilities for Android 11 and using AOSP instead of LineageOS. [/quote] Daniel - is there any thing you *would* recommend in place of Waydroid for use in Qubes?

[DemiMarie]

For context: I think it is reasonable to assume that the apps being run are not trusted, and that each app is in a separate VM.

[emanruse]

A more recent discussion which referenced the current issue:

https://forum.qubes-os.org/t/android-template-qubes/28271/