Port Qubes to ppc64 [3 bitcoin bounty]

[Rspigler]

QubesOS is the most secure operating system available, by far. However, it unfortunately only runs on the x86 instruction set, which runs on unauditable and insecure firmware. The Power Architecture is a much more secure ISA. Products like the Talos II (edit: and now much more affordable Blackbird) with the Power9 CPU are fully open, with auditable schematics, firmware, and software - and being able to run QubesOS on such devices would be a huge win for the infosec community.

There are various ways to achieve this compatibility, so I thought that this issue could be a way to track them/discuss.

1 - Xen could have a ppc64 port (Raptor Computing Systems has offered free hardware to incentivize)
2 - Using the seL4 microkernel (#3894), which is already looking into supporting the Power Architecture
3 - Qubes' Hypervisor Abstraction Layer (HAL), which utlizes libvirt to support multiple hypervisors, yet currently only supports Xen, could be expanded to support KVM, to run on ppc64.

March 26, 2022: We are now all in agreement for Xen+Power (option 1).

Funds available as of May 7th, 2022:
I (Robert Spigler) have 0.35 bitcoin & Blackbird Bundle
@Leo-LB has pledged 0.8 btc (need to confirm)
Total 1.15 btc

@madscientist159 Has offered to do the Xen port for 2 btc (just Xen port; no Qubes integration yet)

Power Foundation has made a statement of support (https://twitter.com/OpenPOWERorg/status/1504112361975730186?s=20), but this needs to be clarified.

We will be moving from Github -> Gitlab for development.
(https://gitlab.com/groups/xen-project/-/epics/6)

We have made a Mailing List and Matrix Room:
qubes_port@lists.riseup.net; https://lists.riseup.net/www/info/qubes_port
https://matrix.to/#/#qubes-port:matrix.org

We have now adopted this milestone approach for this Port: (done here)

1. Phase 1: 0.65BTC. Build tooling, minimal boot to serial console of a Xen kernel on a single core (no SMP, missing drivers, core locked at 100% power).

2. (Proposed) Phase 1.5: 0.65BTC (Pricing subject to change due to economic fluctuations):
   SMP, some driver integration (possible power state management?) required to get a usable system in preparation for Phase 2

I (Robert) donated 0.65 bitcoin out of my remaining 1 bitcoin bounty to fulfill the Phase 1 requirement. See here

@Rudd-O donated the entirety of his bounty (0.5 bitcoin) towards Phase 1.5. He no longer has any remaining pledge, and Phase 1.5 has 0.15 btc left to fulfill. See here

We are still waiting for @Leo-LB to re-confirm his pledge.

Last updated May 7th, 2022

---

Details/History of Funding Below:

Please see the below chronological updates to funding:

• 1
• 2
• 3

In summary, we have a 3 bitcoin bounty, and an additional 0.5 bitcoin remaining for matching funds (deadline passed with 0.5 matching funds filled out of 1 bitcoin matching funds offered - see here). The match offer expired on July 28th 2021.

Details of the bounty are below:

@Leo-LB paid @shawnanastasio 0.2 btc out of his 1 bitcoin bounty here: #4318 (comment)

@Rspigler (me) paid Shawn 0.5 bitcoin out of his 1.5 bitcoin bounty here. I have also offered hardware (Blackbird mainboard and one 4 core Power9 CPU) for a developer who will use it towards this project. See post here.

@Rudd-O pledged 0.5 bitcoin here (has paid 0).

I (Robert) have a remaining 0.5 matching bitcoin offer that expires on July 28th 2021.

Last updated: July 31st, 2022

[madscientist159]

My vote would be seL4. Not only are they responsive to the threat posed by closed, highly privileged firmware, but the kernel is already being used in very high security installations.

[Rspigler]

I would truly love seL4 as well and hope that is the end goal; however, I believe that that course of action would take the longest of all 3. I would argue that porting Qubes for ppc64 (by way of 1 or 3) is of higher priority than working on substituting the seL4 microkernel for Xen, since that offers the quickest route to Qubes running a truly open platform. The security benefit of seL4 could then come after.

I could be wrong though.

[madscientist159]

Of the two, I suspect 3 is the fastest and probably a decent stopgap solution. 1 would be duplicating effort that could go into the seL4 port IMO.

[jaesharp]

If needed, I can provide a significant quantity of build and test infrastructure for this effort.

[andrewdavidwong]

There are various ways to achieve this compatibility, so I thought that this issue could be a way to track them/discuss.

The qubes-devel mailing list is the appropriate place for this sort of discussion. By contrast, qubes-issues is reserved for actionable issues as described in our issue reporting guidelines. If this issue is to remain open, it needs to be action-oriented rather than just a place for tracking and discussion. I'll change the title to reflect this.

[awokd]

I humbly propose this thread: https://groups.google.com/d/msg/qubes-devel/IFLyyCUbLmQ/_HtgOJK4AQAJ as a good place to continue the discussion!

[Peter-Easton]

I have had some difficulty getting to Google Groups, but I'd like to put my vote in as well for a port to the Talos II, whichever the professionals decide it will take the form of. I'm not well-versed enough in hypervisor design to be able to make any meaningful comment on which one would be best, but on the PPC64el, Debian runs KVM quite well with Libvirt for running other Debian and CentOS guests and is happily usable as a desktop with a minimum of work. I'd be very happy to beta-test a port to the PPC64, if you guys need testers.

Not only that but the Talos Lite is now here, which is about the price of high-end business grade or one of those high-end name-branded gaming laptops, and offers far better upgradeability for the future than a gaming laptop even when we don't look at the owner control/openness aspect of it. For many people interested in and serious about security, the price equivalent of a good quality laptop isn't a high one to pay, especially if the user isn't a firmware hacker that has the skills and know how to create their own "trusted stick" like what Joanna Rutkowska was suggesting for a stateless, verified boot x86 laptop.

[tlaurion]

The OTF funding form is here.

Time to tag developers, fund grant filling people (@mfc!) that might help so the discussion can follow on google groups and the information for the grant gets filled for the next OTF round!

[mfc]

hi all, i don't have any capacity to help out right now, but realistically i don't think OTF would fund such effort.

their target group is non-tech-savvy users in at-risk environments. these users have the current computers they own, they don't have the money/luxury of buying new hardware. Qubes' existing hardware requirements are already a very high barrier for these users and their target audience.

so if anything they would be more interested in funding Qubes development onto phones than Qubes on ppc64.

not stopping you all from submitting a proposal to OTF of course. maybe this is more something for a crowdfunding approach, for example.

[Rspigler]

Understandable. Going ahead with both might be possible. If a crowdfunding approach were to be done, what would be the estimated target goals for the KVM approach, and the seL4 approach? (seL4 could possibly be set as a stretch goal).

[marmarek]

As for KVM:

Well, the first non-trivial task would be research what really needs to be done. There are two main parts here:

1. add KVM support in general
2. solve ppc64 specific problems (including verification of devices isolation etc)

The first one is much more predictable, I think it basically is:

• implementing vchan using KVM-specific mechanism
• implement "driver domains" (running a disk/net/usb backend in separate VM, instead of the host) - this is major feature missing in KVM compared to Xen; there are possible workarounds sacrificing some security
• add support for KVM to GUI agent/daemon - one hypervisor specific part there is accessing actual window composition buffers, using shared memory mechanism provided by particular hypervisor
• adjust startup scripts, libvirt configuration etc
• test everything and fix bugs

I think we should assume 50-100kEUR goal for this part alone. Note it may be also beneficial for other architectures, not only ppc64.

The second part may take several months of work, but also may turn out to be trivial. Require someone knowing ppc64 architecture (which I don't know).

For seL4, I don't even try to provide any estimate, without doing some research on the current state of it and what features crucial for Qubes are missing. See FAQ for some hints.