I suspect most phones do not have proper IOMMU. But Pixel phones have this (and hopeful pixel tablets will have that too.
GrapheneOS has something like qubesOS in the long term road map. But not in the comming months, for sure…
I am not technical enough to judge, but google fuchsia seems preety promissing in the long run too (as an alternative to xen)
1 Like
The closest thing we have on smartphones is using profiles on android or some “compartmentalization” things on android (can’t remember their names).
But there is interest in doing smartphones on Qubes OS:
2 Likes
Isn’t that a x86 feature only ? I’ve read ARM defines its version of IOMMU as System Memory Management Unit (SMMU)[13] to complement its Virtualization architecture (wikipedia-IOMMU).
Hmm, recently watched a video about Fuchsia, you’re talking about microkernels ? Cause I don’t remember it was about virtualization, rather abandoning “monolithic kernels” ?
By the way, no need for a IOMMU if there’s no DMA, but again I may be wrong.
The chart linked from fsflover shows Android apps 9 can be run in Anbox, is that it ?
Damn, I have so much things to learn, as if x86 wasn’t complicated enough ^^
Have a look at Fairphone’s mentions here: Frequently Asked Questions · Wiki · Librem5 / Librem 5 Community Wiki · GitLab.
Key takeaway:
many component suppliers (like Qualcomm) don’t release new drivers compatible with new kernel versions, so many Android phones have to stay with the old kernel when they upgrade Android. The most extreme example of this is the Fairphone 2 whose last official upgrade in December 2019 was Android 7.1 with Linux kernel 3.4.0, that was released in May 2012. Even when installing a community port of AOSP like LineageOS, it will often use the same kernel that was last provided by the phone maker.
Basically, the main problem is proprietary drivers that prevent upgrading the kernel. All drivers must be free.
1 Like
Damn the 500k fees from google … And [google] has a policy of only supporting its Android releases for 3 years is even scarier … And people (including me) think microsoft is evil with such short Windows EOLs …
But one should always read with caution the comparison of other solutions from a competitor, even if on fair/objective grounds ^^ I won’t disagree though, I had this answer from fairphone :
But the same precaution as above applies of course ^^ And the other part of the answer, about repairability didn’t convince me a lot (no MoBo/SoC exchange possible, some repair operations need to send to customer support, etc).
Can only wish the same, but it does not feel like the trend … It’s like having a driving license per car brand, and issued by the car manufacturer ^^
1 Like
But there is interest in doing smartphones on Qubes OS
This is about running Android/GrapheneOS WITHIN A QUBE on Qubes OS. It is NOT about running Qubes OS on a smartphone. I am sure this is what @deeplow meant, but at least for me (non-native English speaker) it wasn’t clear from the above sentence.
2 Likes
Not to mention it’s quite possible that running full-blown Qubes OS would need a pretty hefty battery, otherwise the phone would be permanently plugged into the wall.
For those of you who have used the PinePhone, you’ll know that it generates quite a large amount of heat, and the battery (at least, at the time of posting this) barely lasts for half a day when idle. I would imagine running Qubes OS in its current form on hardware like that would probably be incredibly slow, if it didn’t melt the phone case first…
Not to mention the amount of RAM the phone would need! 
Another thing to consider is the use case. I definitely agree that it would be totally awesome to carry Qubes OS around in your pocket, but would I use Qubes OS as a phone? Probably not. Why? Because I probably wouldn’t be using my phone to do the things I use Qubes OS for.
I don’t really plug anything into my phones except for headphones and a charging cable. (I am aware that some people might plug in other things, though).
It would be nice to see Qubes OS on ARM one day (and I will gladly help out where I can), so that we could see it on machines like the PineBook Pro, Surface ARM, M1 Macs, SBCs (the RockPi 5B looks like a seriously good candidate for Qubes OS).
It would also be awesome to touchscreen/stylus integration, because quite a few laptops come with them now. Again, happy to help out where I can on this.
But as for Qubes OS on a smartphone….well……so much of it would need to be changed that it probably wouldn’t be the Qubes OS we know and love any more….
1 Like
I don’t even use a smartphone yet ^^ Why is that ? Better kernel/system optimizations on Android than on Linux ?
Dunno what the typical smartphone usage is, but from what I see from my friends, it’s merely messaging and browsing. With adequate slim VMs that wouldn’t require that much RAM (but power for sure).
I see plenty of use cases. Smartphones are “just” compact laptops, and store a lot of personal stuff nowadays, along casual/dangerous activities (browsing, using public wifi hotspots, etc).
Qubes is good at compartmentalization, hardware and software.
For example, I know for sure that some bank forces you to use an app to validate online payments from a smartphone, which is strange with so much vulnerable Androids on the market. Validation does not work on their website, and the app is only available from google/apple stores …
1 Like
If Linux went from PCs to mobile phones, Qubes OS can too. And it will, yet not soon for sure.
I love your enthusiasm, both of you. I really do. 
——
Mainly because GNU/Linux as a smartphone OS “isn’t quite there yet”. It’s well on its way to competing with Android, but it’s still a little heavy on power draw, unless you don’t mind charging multiple times a day…
PureOS, Phosh, KDE Maui, JingOS, and PostmarketOS have all made massive strides in the space, though, so we’re very close.
So are routers, switches, some light bulbs, and some kitchen appliances. They’re “just compact laptops” too.
Embedded, IoT and battery-powered SBCs are a whole different kettle of fish when it comes to the Linux kernel and board components……
They’re often designed from the ground up for maximum battery life, so they often strip down everything that is considered “non-essential”, both from a hardware and software perspective.
A lot of MIPS, PowerPC, ARM, and ARM64 SoCs lack the basic instruction sets to even run Xen, let alone any kind of virtualisation.
The chips are often designed to do one thing, and do it well, and use as little power while doing it.
While these chips can usually execute most code compiled for it, depending on system resources, it may not be able to do it at a fast enough rate to make it “usable”
An example would be compiling the GNU C Compiler (gcc-10). On an Intel i7-10210U (x86_64) using all 12 cores @ 3.2GHz, this would usually take 3-4 hours.
On a Raspberry Pi Zero with Broadcom 2835 (ARM with 1 core @ 400MHz, this will take SEVEN TO NINE DAYS.
Is it doable? Absolutely. Should you? Well…. It is very satisfying when you see it finish building…. 
Because everything is in a VM. If this was running on a smartphone, under the current Qubes OS model, you’d be running at least 3 VMs:
- sys-net(-usb)
- sys-firewall
- AppVM
Not only does each VM need dedicated resources, spinning them up and powering them down uses a little bit more wattage than just leaving them open, making the battery charge not last as long. In some cases, depending on how many VMs you spin up and power down, could be significant enough to make it not viable against other options like containers or jails.
Honestly, for that use case, it would be easier to have a dedicated phone for that app, even if it was a cheap one…
If you’re worried about apps touching things they shouldn’t be, then it’s better to have nothing worth touching on that machine/device/smartphone.
Qubes OS would definitely be much more fun
——
Don’t get me wrong, having Qubes OS in your pocket on-the-go would be a dream come true, but it would need a MAJOR facelift to get it working optimally, not just for battery-powered devices, but also touchscreens/styluses, accelerometers/ambient light sensors, and things like ZRAM, for it to actually be attractive for daily use.
Arduous, but not impossible
On another note:
There is a handset called the ASUS ZenFone 2, which has an Intel Atom Z3580 CPU in it.
There is a small chance that it might Qubes (yes, I used it as a verb)…
If anyone can get their hands on one, please let me know where you got it from. I want one so I can actually try.
OR….
It might actually be easier to create a phone from an x86 SBC built to run Qubes OS with a “Phone VM”
The AMD Ryzen R1000 Embedded Series or the Up Squared 6000 Series if you prefer Intel would be decent starting points….
I think so and box and another one called island or something.
Here’s another tip: compartmentalization on phones by having multiple ones? Many already have a work phone and personal phone. For the time being, this may be the best solution. It just doesn’t scale as well as Qubes OS in terms of the number of compartments you can have.
@deeplow Well sure, but so much hassle ! I already find smartphones big enough (compared to the w880i) ^^ But ok, no solution is perfect !
I said smartphones are laptops in the usage way, but your examples show how a Linux system can be stripped down. After all Android is a heavily modified Linux. And one day we will have mini/nano/pico kernels to play with !
Atoms can use virtualization ?
Yeah ok, you start then 
Someday I wanna try a Raspi4-based phone as Xen works on it. It would be the first way to Qubes it.
And via GPIO it supports a lot of what a phone would need, and maybe the HW isolation (serial protocols, no DMA) ? Less VMs would be needed then.
I also think Qubes should tend towards a “scripted install”, rather than being provided with a dom0, that would facilitate installing on other distros and hardware. But I guess that’s a lot of work.
I’ve also read (a bit) about dom0less on ARM, but I dunno how Qubes would work then.
Yeah, it’s not always about efficiency ! Just toys ^^ And like your gcc compiling on Raspi0, it’s a matter of “make it work”. After all I’m trying Qubes nested despite all recommendations, so on a phone … Next step ? ^^
Don’t you ever open untrusted websites (with javascript) on your phone, or untrusted apps? How about Bluetooth?
My Pinephone lasts 24+ hours in suspend, so you’re doing something wrong. I use it as a daily driver. It’s sluggish, but getting better.
PinePhone Pro with Manjaro KDE that it shipped with?
I can honestly say that I don’t use either of those things. I actually pull out my Qubes laptop and spin up a dispVM. I don’t have any Bluetooth peripherals that I use with my phone. The most common Bluetooth peripheral that I would pair would be game controllers, and even then I prefer the cables….
I’m also aware that I’m probably an outlier in this regard, and that a lot of people probably would do these things on their phones, so I can definitely see the appeal, and would love it to be a reality.
1 Like
They don’t have the VMX flag, but they can still run paravirtualised Xen, which while it might expose you to hypervisor attacks, it would still count as “running Qubes OS”…
Would be a good hardware benchmark, at least.
Is this what you’re talking about?
Or do you mean having a non-Fedora dom0?
Or something else?
Like this?
Ok, so you want to have Xen with VMs stacked on top of it.
So a separate VM for:
- the baseband modem
- the Wifi and Bluetooth
- your contacts, passwords, history and logs
- your app data
- your photos
- any ports on the phone + cameras
There is no malice in anything I’m saying. Just trying to help this idea along
No to both.
I compartmentalise by using different phones, and burners take the place
of disposables.
4 Likes
Well, a mix of last two ^^ The link you provided, if I understood correctly, is a “normal” Qubes install, except it’s unattended. One example use case I see would be IT guys of media companies using this to auto install pre-configured Qubes on the journalists computers.
What I rather meant is that Qubes can be a “meta package” for any distro (like Xen is). You install a distro, you pull scripts or packages, and it adds a “Qubes overlay” and modifies your system accordingly. This would allow running simpler, lightweighter dom0 distros.
I think it’s being thought of by the Qubes team, as IIRC the question was asked in the survey about using other distros for dom0. For example, I see more people using Debian-based domUs than fedora, but it’s only an impression from what I read here, I may be wrong.
Also, now that we have GUI, audio and input domUs, dom0 is handling less and less devices, hence largely reducing its footprint (no X needed, etc), and so its ressources. Paving the way for my phone idea ? ^^
Yeah kind of ! But I’ve thought about it a bit more, there’s a major drawback using a Pi4, its power consumption. There’s no need for Ethernet and 4 USB ports. What would be needed is a Raspi0 form-factor with the Raspi4 CPU, so it would work with Xen. From what I understood on the Xen wiki, only the Pi4 works with Xen, and I think it’s because of the new CPU.
I only threw the idea, didn’t think about it thoroughly ^^
But using a Raspi, devices are plugged via GPIO using serial protocols (SPI, i2c), even the screen.
I don’t know how it works under the hood, but it could reduce the number of domUs, as less isolation would be needed. Each device can be on a separate “bus”. Plus on ARM there’s this thing called dom0less, so one less domain to run. And as the touch displays also handle inputs, it could be a GUI+input domU. Or maybe it’s rather a security problem … ^^
To reduce power, you could pause the domUs when in idle. For example, why would firefox or your contacts app be running on idle ? You only keep the SIM chip in a reduced power mode to handle incoming/push activities (calls, sms, etc). This would balance (a bit ^^) the power cost of waking domUs when you really need them.
There’s certainly many more aspects to think about !
No offense taken, on the contrary ! It’s the sharing and confrontation of ideas that make better things happen ! Also, if an idea is stupid, it’s better to be told ^^ But here I think it’s more that technology is the barrier.
It’s still dusk, but “utopias of today are the realities of tomorrow” (Mark Twain) ! So let’s be pioneers ?
That’s one of the reasons why I like Qubes, it’s pioneering. It’s not accessible to the masses now, but Rome didn’t build in one day, so I’m sure it will be (at least I hope).
Way to go for the planet Just kidding, but it emphasizes that a Qubes-like system on phones could be useful ! You use one computer for everything, but many phones, isn’t it paradoxal ?
I mean in theory, in practice I may see why.
1 Like
So then, what other potential applications would Qubes OS on a smartphone have?
- Suspicious apps inside their own VM
- Disposable VMs for opening suspicious files
- Compartmentalisation of hardware (baseband modem with “black box” proprietary firmware, Bluetooth, cameras, microphones)
- A perfect use case for “Qubes in the Cloud” (maybe even interacting with your Qubes OS desktop machine?)
- What else?
Just some additional prerequisites:
‘Qubes’ on phone would require a hardware partner. To ensure secure ‘sys-usb’/secure interface for mobile equiv - instead of insecure direct access to cpu of phone peripherals. And to ensure hardware button would be controlled by dom0, so you can leave domains with full screen control.
Also, you’d have to address the fact most android apps require IMEI and all sorts of other hardware information AND that they don’t like virtualised or rooted environments. SO you’d basically have to come up with a way of passing them through whilst maintaing your virtualisation - this really isn’t trivial; given that it’s not secure/private to just pass them through, you’d actually have to pay somehow for multiple sets of these details for use in separate domains OR work with android to adopt a virtualised standard (i.e. which allowed 10 IMEIS per device) - not trivial at all.