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 …
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….
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 ? ^^
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.
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
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.
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.
Honestly, just the ability to have separate environments on the phone would be great. For instance a separate android instance for banking app (as my country now forces you to have an app, no banks offer practical alternatives). An instance for untrustworthy apps, etc.
I do not feel comfortable using an android phone, and until I can have one with proper virtualisation I never will. It is however essentially impossible not to have a phone in my country. So I just assume that the phone is full of malware and try not to worry too much about the prospects of having my bank drained because of it.
@alzer89 I think you’ve cornered the use cases. Well at least mine ^^
But @Quser59 pinpointed a technical question : would a Qubes OS for smartphone use Android as dom0 ?
I don’t think that’s feasible, the easiest way would be to re-use the existing code base, so Linux.
An Android OS should be launched as a domU. That also allows having different templates for different app stores (the official and the open source ones).
I have no knowledge of how a SoC works, so I don’t even know if they are capable of PCI-PT like capabilities. I have also no idea if ARM’s equivalent of the IOMMU would work in our use case.
That’s why I proposed to start using serial protocols (via GPIO or HW serial ports) on Xen-capable ARM CPUs.
The hardware part is always the harder to bend to our wishes.
Just as you can launch x86 android in Qubes now, does not mean you need an android dom0.
dom0 would be some minimal linux, as with qubes now.
Xen on Arm is not the issue. Qubes needs porting to it.
Further, smartphones are different to laptop computers. As above, cameras directly interfacing with the CPU (i.e: mipi), cannot be detached/attached in the way a pcie or usb device can on an intel x86 cpu - as far as I’m aware.
None of this is impossible. but don’t expect it from any manufacturer any time soon. If it’s going to happen, then it’s going to be its own project. There are many, many hurdles to overcome and no economic incentive for a mainstream manufacturer to do so.
Unfortunately Qubes user base is niche, and the market for a phone may have a large backing, but relative to the funding required, not currently large enough.
not sure if QUBESOS would be usable (or useful) on a smartphone… without major changes. Fuchsia ond gVisor would better approach, maybe?
On the other hand porting to ARM would a step forward, away from the rotten x86 arch.
XEN now supports ARM, so (theoretically) suitable for QUBESOS, as long as hardware supporting SMMUv3 (System MMU Support – Arm Developer) would be available (apple M1 does not seem apt for the task, unfortunately, does not even permit type-1 hypervisor!)
Anyway, none of this will happen anytime soon, at least without a serious inrush of money to the project, I guess.
To caricature it, not only to arm, if Qubes wants to survive, it has to be ported to browsers, like everything else will in most of ten years from now. That’s how I see the trends, browsers eating gigs of RAM and everything alike.
