Are there any real obstacles for a (theoretical) ARM port of QubesOS?

[Tom Li]

Hi all.

I knew this topic has been discussed before, but I would like to restart this question for a more detailed answer: Are there any real obstacles for a theoretical ARM port of QubesOS? ARM remains the most viable choice in the world of alternative computer architecture to x86_64 - although ARM as a whole is far from pure from a technical or security standpoint, but it is widely available at a reasonable price, and can offer workstation-level performance - unlike POWER9, which is too expensive and only available from IBM, and unlike RISC-V, which has a lot of promises but no deliverable products are to be expected in the short-term. Thus, it would be interesting to see QubesOS running on ARM (that being said, I'm not attempt to lobby for such a project, my question is purely theoretical). 

As far as I can see, it would be a doable project if one can solve the following problems:

Q: The hypervisor should run on ARM

A: Xen already supports ARM.

Q: Xen support of ARM is new and may be unstable.

A: This can be a real problem. But if my understanding is correct, the flesh and bones for ARM support already exists in Xen. If we are lucky enough, reporting minor bugs to Xen is all needed. If we are not lucky, we would need the help from a Xen expert. Nevertheless, in either case, no groundbreaking development is needed here.

Q: The CPU must have IOMMU capabilities.

A: Even without IOMMU, QubesOS can still be used, although at the expense of reduced functionality (instability to attach hardware devices to an HVM) and security (exposing Dom0 to untrusted hardware). On the other hand, even running on CPUs without IOMMU, QubesOS is still valuable to defend users from userspace-only attacks. With ARM, this argument is still valid - the port can still work without IOMMU, not need to mention that IOMMU can be supported later on, when the circumstance allows.

Q: A suitable operating system is needed for Dom0 and DomU.

A: In Fedora, the general AArch64 support is already in place. Theoretically, swapping Fedora x86_64 to Fedora AArch64 is enough. Indeed, in practice, preparing a suitable template requires a lot of labors, but from a technical standpoint, there's no real difficulties.

Q: It is needed to build all the QubesOS utilities for ARM.

A: Yes, this is a problem. At minimum, the QubesOS build system needs to add ARM support, and worse, it is better to add cross-compiling functionalities to the existing build system. But it is more of a toolchain problem, than an architectural problem.

Q: It is needed to port x86_64-dependant native code to ARM.

A: Tools and glue code in QubesOS is written in a portable programmable language (ISO C). I don't think any QubesOS tools is written in assembly or uses x86_64 specific feature (excluding the hypervisor, which is already ported to ARM).

Therefore, as far as I could see, I don't see serious technical obstacles preventing one from porting QubesOS to ARM. If one put enough labors to the project, theoretically, there is no real technical obstacles to stop one from succeeding.

Have I missed something? I'd glad to hear your opinion.

Tom Li

[Vít Šesták]

> security (exposing Dom0 to untrusted hardware).

IIUC:

1. Missing IOMMU also means a malicious DomU with a PCI device can attack dom0 through DMA.
2. Actually, IOMMU does not fully protect dom0 from a malicious hardware, because a malicious hardware could alter the boot process.

[Rafael Reis]

I recommend reading Joanna's take on Arm architecture:

Chapter 9.

https://blog.invisiblethings.org/papers/2015/state_harmful.pdf

Rafael