I am building a laptop with physical isolation and hardware kill switches

By “physical isolation”, do you mean isolation between hardware devices?

It seems you’re doing this via USB which isn’t a good idea. USB is complex and has plenty of vulnerabilities. An IOMMU would be far more effective.

By physical isolation, do you mean isolation between hardware devices?


USB is complex and has plenty of vulnerabilities.

Thanks! I never thought about that.

I believe the exploit chain you described is: (Correct me if I’m wrong.)

  1. Malicious USB devices connected to the SBC can compromise SBC’s USB host controller
  2. Since host controller can do DMA, the SBC itself can be compromised (or for whatever reasons SBC itself was compromised)
  3. As long as the SBC itself is compromised, it can be turn into a malicious device that compromises C201’s host controller and eventually compromises C201 itself.

An IOMMU would be far more effective.

I am sure Cortex-A17 has support for SMMU (ARM’s IOMMU) 1, therefore RK3288 should also supports that, but I haven’t confirm it yet.

And TBH, I have no idea about how can I use this, Linux kernel’s documents for ARM 2 don’t have a section about SMMU.

If I understand the problem correctly, this is a hardware problem and softwares such as USBguard can do nothing to fix it, right?


There seems to be some documentation here https://www.kernel.org/doc/Documentation/devicetree/bindings/iommu/ and the source code is https://github.com/torvalds/linux/blob/master/drivers/iommu/arm-smmu.c if that helps.

I don’t have any idea on how to use SMMU either though.

Yes, USBGuard just denies access to certain USB devices. It doesn’t setup any isolation.

I think I should be able to disable DMA by forcing PIO mode using AM335x’s CONFIG_MUSB_PIO_ONLY kernel option, so I don’t have to touch SMMU.

This is expected to dramatically reduce the usable USB bandwidth, but I still don’t know how much. I will test it and see if that’s still usable.

As open as possible. Meaning you publish how you made your laptop so others can assemble the parts and create something like it.

Why? For freedom.

1 Like

Now I am running a kernel with


… which disables all the DMA USB controllers:

static inline struct dma_controller *
musb_dma_controller_create(struct musb *m, void __iomem *io)
        return NULL;

static inline void musb_dma_controller_destroy(struct dma_controller *d) { }


So I assume that DMA via USB is now disabled, but I still can’t confirm that, do you know how can I confirm that?

Everything seems to be working!
WLAN is a bit buggy, but usable.
Not sure if that’s due to software or hardware.

I think I can start dogfooding now :slight_smile:

No, I wouldn’t know how.

1 Like


I just confirmed that both C201 and PocketBeagle are mainlined.

Now the latest ti-linux-kernel-dev for PocketBeagle is 5.4.20-ti-r6.

I also ported stock Debian and Alpine Linux to PocketBeagle, everything seems to be working :slight_smile:

Welcome to Alpine Linux 3.11
Kernel 5.4.20-ti-r6 on an armv7l (/dev/ttyS0)

alpine login: 

Next step: try to run whonix-gateway-cli using distro-morphing .

1 Like

Nice. Just FYI distro-morphing is experiencing bitrot because it has been deprecated (contributions welcome if you or anyone is interested). Complexity make its maintenance very impractical.


As for distro-morphing there’s some bad and some good news. Updated its dedicated forum thread just now to elaborate on that. See:

'sudo apt-get install whonix' Part I / Distro-Morphing

1 Like


Thanks for the link!

I don’t think this will affect me since I am doing distro-morphing on top of a clean debootstrap-ed buster rootfs.

The major problem for me is, while the rootfs works perfectly, many critical parts of KickSecure are not available for armhf, including:

I am now porting anthraxx/linux-hardened to armhf, though not sure how hard it’s gonna to be.

Just read Whonix/Verified_Boot, and I think I should be able to implement verified boot on C201 using Depthcharge.

I really hope I got more time to put into this project.

Awesome. Please try to get it maintained by anthraxx upstream.

Yeah some of the stuff in KSPP is for arm though because of Google’s interests. The fact most projects are x86 centric is caused by legacy baggage and networking effect. However it is very valuable having a viable alternative platform until development catches up.

There was interest to port Tor Browser to arm by namecoin lead dev on Tor mailing lists. They may renew interest if they see privacy projects targeting the hardware. Even without TBB for Linux, a private arm laptop is still more valuable than not existing.

Does the board support virtualization? Have you tried KVM on it?

1 Like

linux-hardened was only ever meant to support x86_64 and arm64. Other architectures are out-of-scope.

Right. OP’s board is arm64 I believe.

I believe this board isn’t arm64, because uname shows it’s a armv7l, and the first arm64 processor is based on ARMv8-A.

1 Like

I see. You do what you see reasonable, but if I were planning such a project I’d go for a arm64 board to make it more future proof. Think virtualization, hardware security extensions, 2038 clock bug, UEFI support.

Well, I probably underestimated the complexity of this project…

If I can start again I will probably use something more future-proof such as PineBook Pro.

As for the virtualization, I don’t know how useful it’s gonna to be on boards with limited RAM and CPU resources. AFAIK, even high-end boards (e.g. RPi 4, PineBook Pro) have only 4GB of RAM, minus at least ~500MB required by a Gateway VM and a host system, the amount of RAM left might not be enough for user to do the actual work.

That’s also why I prefer to use some kind of lightweight container rather than virtualization.

However, I believe it’s possible to run KVM on C201, but I might have to hack the firmware to start the kernel in HYP mode.

Some useful links:


Well, it might be just enough for some basic work. 500 MB isn’t that much. Now, let’s say it’s 1GB. That would mean there would be 3GB RAM left. This should still be enough for usecases were you don’t have lots of tabs/programs running at the same time. Yes, most ARM SoCs, while being capable of 64-bit calculations, only have 32-bit memory addressing, which means there’s a limit of 4GB most of the time, thus that’s the most one would typically see soldered to such a board. There are ARM boards (not actual SBCs though) that support more, such as the HoneyComb LX2K by SolidRun, however this won’t really be usable in a laptop. Same goes for other alternative architectures, for example, there are the Talos II and Blackbird mainboards by Raptor Systems, which use POWER9 CPUs. While certainly supporting enough RAM, and also an interesting platform for something like Whonix, they’re not usable as a laptop.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]