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

Development
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

Hi everyone, I am building a laptop with physical isolation (via a dedicated single-board computer (SBC) ) and hardware kill switches, I just finished the first prototype and it’s usable!

Now I want to share my ideas with you and possibly get some feedback from the Whonix community.

This thing is based on a Asus C201PA (Gentoo Wiki, Debian Wiki) , which is a Rockchip RK3288-C (Wikipedia, Rockchip Wiki) based Chromebook. It’s Libreboot compatible and does not require any non-free blob to operate.

Kernel / Drivers

Most of it’s features, including LCD and HDMI video framebuffer, eMMC, microSD, battery, and USB is available in mainline linux since v4.8-rc2.

It’s Mali T764 GPU comes with non-free driver, but xserver-xorg-video-fbdev works just fine.

It also has a soldered on M.2 Type 1216 WLAN + BT card that requires non-free blob to operate, but we don’t need it and can be (easily) removed by using a SMT rework station.

SBC1

The SBC I use to perform physical isolation is a PocketBeagle, it’s small enough to be put inside C201’s case, and can be powered directly by C201’s motherboard.

The PocketBeagle is a open source SBC based around a OSD335x-SM System-in-Package (SiP) (Specs, PDF Datasheet), according to eLinux Wiki, it’s mainlined as well, although I haven’t confirm it yet.

Internal Diagram:

 --------
 |      |    |-----|--[ * SBC ]------------------------[ USB hub ]
 | C201 |----| USB |                                |       |
 |      |    | hub |                                |       |
 |------|    |-----|--[ * USB to serial adapter ]-----------|
                                                            |
                              [ * USB Port ]----------------|
                              [ * WLAN Adapter ]------------|
                                               

- - The parts labeled with * can be controlled individually by kill switches
- - Once the power of the serial adapter is turned of, it should be impossible to reveal user's real IP address even when the C201's OS is fully compromised

Connection Diagram:

Wired:     [ Internet ] ---- [ Ethernet Adapter ] ---- [ SBC ] ---- [ C201 ]
Wireless:  [ Internet ] ---- [ Wireless Adapter ] ---- [ SBC ] ---- [ C201 ]

Features:

    • Physical isolation via dedicated SBC
    • Multiple hardwired kill switches with LED indicators for controlling SBC, serial adapter, WLAN and SBC’s USB port
    • Open firmware, zero non-free blob required
    • C201 itself can be stateless by booting from a microSD Card, which can be easily physically destoryed within 5 sec.
    • Low overall power consumption
    • Lightweight, about 1.03kg after mod
    • Low cost, should be under 200$ (C201: 100$ + SBC: 40$ + Serial: 5$ + Hub: 5$ x 2 + Switches/LEDs: 5$)

What’s next:

    • Port TBB (Should be possible, someone has done that on C201 before)
    • Port Alpine Linux and use it as the base system?
    • Make some kind of sandbox / container layer (Maybe LXC?) for risky applications (e.g. Firefox)
    • Port as many Whonix security feature to it as possible ← Maybe just ports Whonix itself to it?

Please let me know what do you think about this! All feedback are welcomed!

This is posted from my prototype system, with Tor running on SBC :slight_smile:

P.S.: Sorry for the long inline signature, I can’t get a secure email address when using Tor, so I have to use a temp. address to register. The following key should be online on pgp.mit.edu soon.

pub rsa3072 2020-04-07 [SC] [expires: 2022-04-07]
AAACDA2D2E49CF6DA72AB8D97DB140229CC5EED3
uid [ultimate] Yoshidako yoshidako@example.com
sub rsa3072 2020-04-07 [E] [expires: 2022-04-07]

Quick Specs

PocketBeagle
  • RAM: 512MB DDR3
  • CPU: 1-GHz ARM Cortex-A8 (armhf)
  • Based on Octavo Systems OSD3358-SM 21mm x 21mm system-in-package
  • ARM Cortex-M3 + 3D accelerator (Not sure what Cortex-M3 is, the CPU is Cortex A8)
  • 2 x 2-bit 200-MHz programmable real-time units (PRUs)
  • Power / battery management
  • EEPROM (Not sure what is it for…)
  • 72 expansion pin headers
  • 8 analog inputs
  • 44 digital I/Os
  • High-speed microUSB host/client and microSD connectors
  • System Reference Manual
  • OSD335x-SM Detailed Block Diagram
Asus C201
  • SoC: Rockchip RK3288-C
  • CPU: 4 x ARM Cortax-A17 @ 1.8 GHz (armhf)
  • RAM: 2 or 4 GB DDR3
  • GPU: Mali T764
  • Audio processor: Rockchip I2S
  • Screen size: 11.6"
  • Resolution: 1366x768
  • Touchpad: Elan I2C
  • Board: Veyron-Speedy
  • Battery: 7.6V 38Wh

Useful Links

Installing Gentoo: Asus Chromebook C201/Installing Gentoo - Gentoo Wiki
Installing Debian: InstallingDebianOn/Asus/C201 - Debian Wiki

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEEqqzaLS5Jz22nKrjZfbFAIpzF7tMFAl6MrjcACgkQfbFAIpzF
7tPrxwwAkhgWLrKJcvyJdWpTGZebau75HwN4attCeT0kHVztt6jvia5V5eoLf5ky
6dUYoRbsjizx+cQCt4QfEc7bQUHQmcN0L1fO1Alx0/PlJ12kyqTT3hDhw3VbXp2m
AgvA/5/ic4OLDHhKho1jcz9d+9nt9+LBubZ/jfg8FHussVKK8jrWlsL7OU9ecOtB
JUSYSZPXdyobmspBgFRTG4EmK670Vuy/r6B5R46ctOzW/qQQd3rkV8SlgI6u9Uuh
EK3Svag/FnuBsvq1SA+NRP6XLqudLg14mHkFnjVIQINc6yZhfyE8LTVfcuAuaYid
3HUZ0mKsUTeXNG3nsD2Fim2iGcCmFMm936gxl6k+pxNkzDBjZa9snJ4QKjSyLqXj
t1b/3+sv61mk1wQLT19osa6zhWEEJtIItI2qnjh7IU/oqnB762Il+1+IgMxXrvlD
emUd2h2hBfMSryiMyMLpt5+v1KCq0rLxS29fWe8mAzMwl7oVeocGcglprq3/gzQ4
5D2V6PzM
=Om/E
-----END PGP SIGNATURE-----

2

What’s your goal? Personal machine or development, something re-usable by others?

Would be useful to explain at first use what that means or link to some definition.

Internet says it has Rockchip RK3288 - Wikipedia which is

an ARM architecture System on Chip (SoC) from Rockchip

What Debian platform is that? arm64, armel, armhf or something?

Sounds interesting.

You’re in good luck since only recently arm64 builds were fixed. See: Whonix Development News

Therefore seems feasible that Whonix could also be ported to a lot / most / all platforms that are supported by Debian.

search maybe:

site:debian.org ARM Cortex-A17

I am not convinced that this would be any useful. See:

Security-Focused Operating System Comparison as Base for Whonix

Join:

3

@yoshidako have this board’s drivers been mainlined? It was WIP last time I checked. Publish the schematics on github if you hope to build a community around it.

1 Like
4

Thanks for your feedback!

What’s your goal? Personal machine or development? something re-usable by others?

Both? I will try to use this as my daily driver so I can find and solve problems rapidly.

It will be great if others will be able to reuse this design in future.
But for now, I hope this will inspires some people :slight_smile:

What Debian platform is that? arm64, armel, armhf or something?

It’s 32bit, running Debian armhf.

Debian actually has a page for C201 here: https://wiki.debian.org/InstallingDebianOn/Asus/C201

5

Yes, I believe it’s mainlined ever since v4.8-rc2.

As for the schematics, I am not sure if it’s public because Asus C201 is not an open hardware. Could you show me why is this important?

9

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.

10

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

Yes

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?

11

Yes.

There seems to be some documentation here Index of /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.

12

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.

13

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
14

Now I am running a kernel with

CONFIG_MUSB_PIO_ONLY=y

… which disables all the DMA USB controllers:

#ifdef CONFIG_MUSB_PIO_ONLY
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) { }

#else

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?

15

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:

16

No, I wouldn’t know how.

1 Like
17

@HulaHoop

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
18

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.

2 Likes
19

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 - #6 by Patrick

1 Like
20

@Patrick
@HulaHoop

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.

21

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.

22

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
23

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