Existing Ports of and Porting Whonix to other Architectures

Whonix ®

Download

Windows Linux Mac VirtualBox KVM Qubes Intel / AMD64 ARM64 PPC64 USB ISO Raspberry Pi More options Source Code

About

Overview Features Whonix vs VPNs Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Dev/Password Manager Design Dev/Logo Previous page: Dev/Password Manager Index page: Design Next page: Dev/Logo Existing Ports of and Porting Whonix to other Architectures

• Opening Ports in Whonix
• Porting Whonix to other Architectures
• Porting Whonix to other Virtualizers

• Whonix Installation from Whonix APT Repository
• Porting Whonix to other Architectures

Architecture specific packages in Whonix. "Special packages". Software maintained by third parties. Compiled software. Kernel modules. Shared objects. Tips on porting Whonix to other platforms. "amd64" means Intel and AMD. Porting Simplicity.

Existing Ports of Whonix

• Whonix reported to be running on POWER9 (OpenPOWER) (ppc64), Raptor Talos II using distro-morphing.
• Inoffical Whonix Docker port. Not reviwed by Whonix developers.
  • https://forums.whonix.org/t/running-whonix-on-kvm-in-linux-containers/14048
  • https://github.com/nspin/whonix-now
• Some other inoffical Whonix docker ports of on GitHub.

Incomplete Ports of Whonix

Raspberry Pi - RPi

• Whonix for arm64 / Raspberry Pi ( RPi ) (wiki) (unsupported) See also Raspberry Pi (RPi).

Apple Silicon

• Whonix on Mac M1 (ARM) based: project status / forum discussion

Existing Ports of Kicksecure^™

ppc64el

• ppc64el Kicksecure^™ functional, created using distro-morphing on a test server for Whonix developer Patrick. See also ppc64.

ARM64

• Distro-morphing should generate viable images for KVM on arm64. See also arm64

Notes

Note on Terminology

amd64 might imply AMD only. This is wrong.

amd64 means Intel and AMD.

For technical reasons, in Debian (and in many other Linux / Freedom Software related places) both, Intel and AMD, is called amd64. This is common knowledge without controversy among technical people, in doubt see Wikipedia X86-64.

Virtualization versus Emulation versus Architecture

• prerequisite knowledge: Note on Terminology
• Examples of architectures: amd64, arm64, riscv64, POWER9
• Examples of virtualizers: VirtualBox and KVM.
• Examples of emulators: QEMU and Bochs.
• Virtualizers: The guest operating system architecture must be compatible with the host operating system architecture. For instance, an amd64 host can only virtualize an amd64 guest. It is impossible to run arm64, riscv64, POWER9, etc. inside a virtualizer.
• Emulators: The guest operating system architecture does not need to be compatible with the host operating system architecture. For example, an amd64 host can emulate an amd64, riscv64, POWER9, etc. guest.
• Speed comparison: Virtualizers are faster than emulators, which are too slow for everyday desktop operating system production use cases.
• Conclusion: Debian, Qubes, Kicksecure, Whonix builds for amd64 cannot be run on host architectures such as arm64, riscv64, POWER9, etc. using a virtualizer such as VirtualBox or KVM.
• Porting: To run an operating system on a different architecture, a port is required. The base operaging system (in case of Whonix, that is Debian) needs to be available for that architecture. Furthermore, the derivative (Kickssecure, Whonix) architecture specific packages need to be able to be build for that architecture. This is most likely possible. These packages are documented below. Furthermore, a bootable image (VM or ISO) needs to be created. Depending on the architecture, this can be a difficult process, which is elaborated on Development of System Image Creation and Bootstrapping Tools.

VM images creation using derivative-maker

grml-debootstrap

derivative-maker uses grml-debootstrap to create base bootable raw images.

grml-debootstrap currently supports architectures amd64 and arm64 only. See grml-debootstrap discussion Clarify design goals. For other architectures, please consider to comment in the ticket or create a new one as appropriate.

Raw image creation is a difficult process. See also Dev/image_creation.

Packages

Porting Simplicity

To simplify ports to other architectures, all of the following packages are optional dependencies. These packages have very useful functionality however to simplify bootstrapping a port of Whonix for a quick motivational milestone to reach of Whonix building and booting, all architecture specific packages are optional dependencies by design in Whonix.

Therefore porters do not need to worry about any of the following packages during original porting work.

Most of Whonix packages and all essential packages are architecture independent.

To simplify ports, Whonix repository at time of writing supports the following architectures.

amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc ppc64 ppc64el s390x sparc source

This might be useful for distro-morphing.

Distro-morphing might be the easiest way to create a proof of concept port of Whonix. Following the spirit of Self Support First Policy, first experimenting with Debian (which Whonix is based on) first might be helpful.

A production quality, redistributable port of Whonix however should be created using Whonix build script instead of distro-morphing.

Related: porting Whonix to other virtualizers

bindp

• maintained by third party: yes
• compiled: yes
• compiled when: at package installation time / at Whonix build time
• language: C
• no upstream version number
• documentation: none
• upstream: https://github.com/yongboy/bindp
• package source code: https://github.com/Kicksecure/bindp
• kernel module: no

kloak

• maintained by third party: yes no
• compiled: yes
• compiled when: during package build process / at Whonix build time
• version number by upstream: yes
• architecture support: any
• documentation: kloak
• upstream: https://github.com/Whonix/kloak
• Debian package source code: https://github.com/Whonix/kloak
• kernel module: no
• Kloak Forum Discussion

corridor

• maintained by third party: yes
• compiled: no
• language: sh
• version number by upstream: yes
• upstream architecture support: any
• documentation: Corridor
• upstream: https://github.com/rustybird/corridor
• Debian package source code: https://github.com/Whonix/corridor
• kernel module: no
• corridor Development Discussion

tb-updater

• maintained by third party: no
• compiled: no
• contains binaries: no, because it is a downloader script
• language: bash
• version number by upstream: no
• architecture support:
  • i386 and amd64
    • For the Linux platform The Tor Project is only providing i386 and amd64 downloads. See https://dist.torproject.org/torbrowser/.
  • arm64 -> https://forums.whonix.org/t/arm64-tor-browser/11806
• Debian package source code: https://github.com/Kicksecure/tb-updater
• kernel module: no

tirdad

• maintained by third party: yes
• compiled: yes
• compiled when: at package installation time / at Whonix build time
• version number by upstream: upstream does not (yet) provide version numbers
• architecture support: amd64 only
  • amd64 support: Yes.
  • arm64 support: No, because the Linux kernel does not support live patching on arm64.
  • Other architecture support: TODO. In theory, yes, as long as the Linux kernel supports live patching on that architecture.
• documentation: TODO
• upstream: https://github.com/0xsirus/tirdad
• Debian package source code: https://github.com/Kicksecure/tirdad
• kernel module: yes
• kernel: Linux only
• tirdad Development Discussion

binaries-freedom

• Currently not in use.

tor

• Architectures amd64, i386 and arm64 are using the deb.torproject.org tor package. A newer version. The latest stable version provided by The Tor Project for the stable release of Debian. Why? See Dev/Tor and https://forums.whonix.org/t/tor-package-urgently-needs-update-to-v0-4-6-8-due-to-tor-browser-11-stable-fingerprintability/12762.
• Architectures other than amd64, i386 and arm64 are using the packages.debian.org tor package. An older version. The frozen stable version provided by Debian for Debian stable. This has a disadvantage: https://forums.whonix.org/t/tor-package-urgently-needs-update-to-v0-4-6-8-due-to-tor-browser-11-stable-fingerprintability/12762
• package maintained by third party: yes
• compiled during package build process: no
• contains binaries: yes
• version number by upstream: yes

Check Tor SocksPort Reachability

On Whonix-Workstation^™. Test.

{{Curl_Plain}} 10.152.152.10:9100 ; echo $?

Should show.

<html>
<head>
<title>Tor is not an HTTP Proxy</title>
</head>
<body>
<h1>Tor is not an HTTP Proxy</h1>
<p>
It appears you have configured your web browser to use Tor as an HTTP proxy.
This is not correct: Tor is a SOCKS proxy, not an HTTP proxy.
Please configure your client accordingly.
</p>
<p>
See <a href="https://www.torproject.org/documentation.html">https://www.torproject.org/documentation.html</a> for more information.
<!-- Plus this comment, to make the body response more than 512 bytes, so      IE will be willing to display it. Comment comment comment comment      comment comment comment comment comment comment comment comment.-→
</p>
</body>
</html>
0

Otherwise, it would be a grave error (Tor SocksPort not reachable).

Check onion-grater Reachability

On Whonix-Workstation. Test.

{{Curl_Plain}} 10.152.152.10:9052

Should show.

510 Prohibited command "GET / HTTP/1.1"
510 Prohibited command "User-Agent: curl/7.26.0"
510 Prohibited command "Host: 10.152.152.10:9052"
510 Prohibited command "Accept: */*"
510 Unrecognized command ""

Otherwise, it would be a grave error (onion-grater not reachable).

Forum Discussion

https://forums.whonix.org/t/architecture-specific-compiled-third-party-special-packages-porting-whonix/8562

RPM

These are some random notes about porting Whonix update debs to rpm.

What would have to be done:

• create rpm package
• Find a replacement for config-package-dev, a package which allows third party packages (Whonix) to own files which are owned by other packages. Such as /etc/tor/torrc is owned by tor, but anon-gw-anonymizer-config includes its own config file.
• add init scripts (currently done by debhelper)
• add man pages (currently done by debhelper and ronn, see debian/rules)
• minor: replacement for dh_apparmor

Footnotes

Whonix The most watertight privacy operating system in the world.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Whonix is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Whonix we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2025 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 13 year success story and maybe DONATE!