Whonix for arm64 / Raspberry Pi (RPi)

Development
,
62

You could try to modify grml-deboostrap to avoid installation of grub-pc or to install a more suitable package. Whatever works. (Sometimes Whonix source code shipped a modified version of grml-debootstrap until patches were merged upstream and flowing into packages.debian.org.)

The grml-deboostrap are responsive and friendly. They fixed a lot issues I posted and merged a lot pull requests of mine.

Issues · grml/grml-debootstrap · GitHub

You could also ask them about arm / file system support.

Change Partition Scheme
https://phabricator.whonix.org/T522

Related, replacing grml-debootstrap:
https://forums.whonix.org/t/debos-build-platform

Not implemented. Patches welcome.

Something like for item in "$WHONIX_SOURCE_FOLDER/packages/"*; do could be used to generate the default list if not set yet. But if set (which you could use then) it could be pre-defined.

I was also considering to change Whonix build script to install from Whonix repository (deb.whonix.org) rather than building packages locally. Whonix may be the only one doing it that way. I wrote about that elsewhere but don’t remember where.
(Whonix Installation from Whonix APT Repository)

Things are difficult enough. Since this is for physical isolation, I wouldn’t mind defaulting to DHCP.

Let me know if whonix-gw-network-conf/etc/network/interfaces.d/30_non-qubes-whonix at master · Whonix/whonix-gw-network-conf · GitHub conflicts. Could a config file with a name such as /etc/network/interfaces.d/40_rpi-whonix overrule what 30_non-qubes-whonix does? Otherwise some Whonix RPI package (maybe you need to invent that anyhow?) could config-package-dev displace 30_non-qubes-whonix. There are config-package-dev displace examples in Whonix source code but I can help with that one since not hard once one got used to config-package-dev.

63

I guess a patch for grml-debootstrap would be available earliest in debian buster so a custom version is required for the rpi at the moment.

+1
That would speed up building everything. Only new packages or locally changed packages would need to be rebuild.

I could cut down the package list to some extend. So the current build time for a complete image is ~ 1:45 h. Without gui things are working well. Still there are lots of unnecessary packages installed like vlc* stuff, kwrite … . Mostly the reason is dependency on msgcollector and sometimes konsole, kwrite, zenity, libgnome2-bin, gvfs, mate-notification-daemon. Packages which install these are at least: whonix-setup, whonix-setup-wizard, whonix-firewall, anon-gw-anonymizer-config. Do you see any possibility to make those dependencies “Recommends”? I guess at least some of those would also be installed by one of the kde-desktop packages? There is also still the question of timesync. I guess the most reasonable way would be to buy a rtc and attach it to the rpi. Otherwise the user would always need to login and set the date manually. From reading this: https://www.whonix.org/wiki/Dev/TimeSync there seems to be no alternative.

1 Like
64

Algernon:

I guess a patch for grml-debootstrap would be available earliest in debian buster so a custom version is required for the rpi at the moment.

Doesn’t matter. No big deal. We can include grml-debootstrap (it’s just
one or two scripts that matter) into Whonix source code in meanwhile
until it reaches buster.

Still there are lots of unnecessary packages installed like vlc* stuff, kwrite … . Mostly the reason is dependency on msgcollector and sometimes konsole, kwrite, zenity, libgnome2-bin, gvfs, mate-notification-daemon. Packages which install these are at least: whonix-setup, whonix-setup-wizard, whonix-firewall, anon-gw-anonymizer-config. Do you see any possibility to make those dependencies “Recommends”?

Only Recommends: probably no. They need to be Depends: of some
package. See Dev/About Debian Packaging - Kicksecure

But they can be Depends: of a package which does not get installed on
cli version.

anon-gw-anonymizer-config fixed:

/

whonix-firewall fixed:

whonixsetup: fixed

whonix-setup-wizard: should not be installed on CLI gateway since it is
a graphical tool, right?

msgcollector: wmctrl already is an “optional dependency”. Meaning, if it
was not installed, msgcollector code would handle it. So that dependency
could be moved to a Whonix desktop package instead. msgcollector
unfortunately is historically grown and isn’t cleanly separated into
msgcollector and msgcollector-gui. But it’s doable.

Please create bug reports / send pull requests, would be interesting to
fix these things.

I guess at least some of those would also be installed by one of the
kde-desktop packages?

KDE: no, not KDE specific. Desktop: yes.

There is also still the question of timesync. I guess the most reasonable way would be to buy a rtc and attach it to the rpi. Otherwise the user would always need to login and set the date manually. From reading this: https://www.whonix.org/wiki/Dev/TimeSync there seems to be no alternative.

You could invent using
TimeSync: Whonix Time Synchronization Mechanism for the
initial rough time fetch. (After that Tor would work and sdwdate would
fix the time with higher precision.) But it may or may not be ISP
network fingerprintable. Even if fingerprintable, may be an ok
compromise. Buying an RTC is probably not something that many users
would do. I don’t think there will be a perfect solution for a device
without RTC.

2 Likes
65

Thanks for the fixes, this cut down the build time even more. Another issue which showed up is the wifi/firmware support. The integrated wifi is only supported in the kernel and raspi3-firmware version from buster. However, the wifi is said to have poor performance so it maybe doesn’t matter anyways, you could always use some USB wifi adapter. Another problem with the old firmware version is some i2c bug which does not look harmful but it is spamming the logs. So either live with that or use some custom firmware package in the build scripts?

66

Algernon:

Another problem with the old firmware version is some i2c bug which does not look harmful but it is spamming the logs.

Can log spam kill sd card?

So either live with that or use some custom firmware package in the build scripts?

Yes.

How would “custom firmware package in the build scripts” look like?

67

Yeah this could occur over time. Messages go to kern.log and the terminal which is kind of annoying. Maybe this could be suppressed somehow.

It would be mostly a more recent raspi3-firmware package + some changes to the kernel commandline in config.txt to enable apparmor + maybe changes for fstab to automount /dev/mmcblk0p1 at /boot + changed network config for dhcp.

btw: whonixsetup needs “ed” package as dependency otherwise it will fail

2 Likes
68

Fixed.

https://github.com/Whonix/whonixsetup/commit/5a47bb0c862bfd45cbcad202ab20b5ccc6c71330

69

There is something wrong with git currently.

git clone --jobs=200 --recursive https://github.com/Whonix/Whonix
fails with:

error: no such remote ref 632c12ca5fada0f65dae5385837bbe712f7a6253
Fetched in submodule path 'packages/apparmor-profile-anondist', but it did not contain 632c12ca5fada0f65dae5385837bbe712f7a6253. Direct fetching of that commit failed.
70

Fixed.

71

From the live thread:

I guess so. It is just the first version and I just put everything needed for a minimal rpi gateway in one package. There is maybe some meta-package which already includes these packages but at the same time does not include more dependencies. I’m not sure about that though.
If the whonix-gateway-rpi package would be the only one using a newly created meta-package it would probably not make too much sense. You’d have two meta-packages instead of one.
But anon-shared-packages-dependencies looks like a good candidate if we remove sdwdate-gui. vbox-disable-timesync would also be not necessary for the rpi but i guess it would not hurt either. bootclockrandomization would install msgcollector which installs a lot of packages, so it would be good to get rid of it.

Some other stuff:
Using some 40*_ file for the interfaces won’t work so either the user does it manually or we create a new network package for the rpi gw and use this as dependency instead of the current package.

If anyone wants to take a look or try to build, patches/diffs can found here:
https://github.com/Whonix/anon-meta-packages/compare/master...Algernon-01:master
https://github.com/Whonix/Whonix/compare/master...Algernon-01:master

You currently need to add tor-control-panel as a dependency to the whonix-gateway-rpi metapackage. You likely also need to manually set the right time and the correct interface address for your upstream router. After that run whonixsetup to enable tor. You currently also need a serial adapter. I could not yet figure out why I just don’t get any output over HDMI. I tested a lot but nothing did help up to now. It worked before with the gui version, so it should not be hardware related.

2 Likes
72

msgcollector / msgcollector-gui split in progress.

73

sdwdate-gui is now in anon-shared-packages-recommended. But that’s not great either. It’s the only gui application in that list. You might want package anon-shared-packages-recommended?

A better split cli vs gui is required. I really want to clean this up otherwise by picking packages things could get forgotten and therefore a non-unified experience / strange bugs.

I think a non-qubes-whonix-gateway-cli package would be great! whonix-gateway-rpi could depend on it plus on what is RPI specific.

msgcollector was split into msgcollector and msgcollector-gui. So just installing msgcollector won’t pull the gui dependencies. It’s not tested yet but I guess it will work ok.

1 Like
74 
   if [ -f "$WHONIX_SOURCE_FOLDER/pkg_list" ]; then
      fi
   true "INFO: Predefined package list detected. Using it for building. "

A user created file in Whonix source code is not great. Whonix buildconfigs are more flexible for that. (Variables and different config folders.)

Could be done similar to this:

All --flavors - including the existing --flavor whonix-gateway could be “equals” in the sense of equality. This would make the code simpler. It’s simpler for all to use opt-in rather than a historic default with workarounds / overrides for new flavors.

  • --flavor whonix-gateway would opt-in non-qubes-whonix-gateway

    whonix_build_script_build_dependency+=" non-qubes-whonix-gateway "

  • --flavor whonix-gateway-rpi would opt-in whonix-gateway-rpi

    whonix_build_script_build_dependency+=" whonix-gateway-rpi "

75 
   ## All architectures currently provided by deb.torproject.org at time of writing.
   architecture_list="armel armhf i386 amd64"
   architecture_list="armel armhf i386 amd64 arm64"

Merged already. And uploaded to Whonix repository.

function get_extra_packages() {

   if [ "$WHONIX_BUILD_FLAVOR" = "whonix-gateway-rpi" ]; then
   architecture_list+=" arm64"
   fi

No need for that since it only downloads VirtualBox guest additions. Also would break since there is no arm64 builds for guest additions.

We can rename get_extra_packages to a better function name after merging your pull request.

1 Like
76

anon-meta-packages split into gui and cli in progress.

77

Are there any packages which would be important for a virtualized cli version of the gateway which are currently not in the whonix-gateway-rpi package? If not I would just split the current whonix-gateway-rpi into non-qubes-whonix-gateway-cli and a new whonix-gateway-rpi.

1 Like
78

For a robust solution, It should depend on the gateway CLI meta packages… Otherwise it’s hard to know what’s missing now and what may be missing in future.

1 Like
79

I have split the rpi meta package into a rpi-specific package and a non-qubes-whonix -gateway-cli package. One could change the Depends of the latter one to include mostly meta-packages but there would need to be some more changes to anon-meta-packages:

“anon-shared-packages-recommended” currently depends on gtk2-engines-pixbuf, anon-iceweasel-warning, anon-icon-package which are all gui packages and the first one pulls in a lot of other packages.
“non-qubes-vm-enhancements” depends on acpi-support, pulseaudio, libasound2, alsa-utils. The first two would also install a lot of unnessecary packages.
“whonix-shared-packages-dependencies” depends on grub-enable-apparmor which won’t work for the rpi. Not sure if the package can be included somewhere else.
If (some) of the meta-packages can’t be changed then we need to include the required individual packages into the non-qubes-whonix -gateway-cli package.

2 Likes
80

Very good!

I am on it now.

81

Fixed.

non-qubes-vm-enhancements is for VMs only so should not be installed on CLI gateway anyhow.

About any packages you need which are currently included in non-qubes-vm-enhancements we can maybe later find a solution in a later revision. Let’s see.

What’s happening? Breaks build? Breaks boot? Just doesn’t enable apparmor in grub kernel command line? If it just doesn’t work I guess it’s just a tiny package we could leave it as is until we can repair the package.

Any error message? Perhaps we can fix it?