Keyboard connection

Framework Laptop 16
1

Hello!
How is the keyboard connected?
I saw it’s hot-swappable, so I fear that it might be USB based. The issue is that if this uses the same USB controller as the expansion ports, this violates the Qubes security model (allowing conpromise and also requiring annoying extra configuration).
So before I get too excited about the laptop: Does anybody know more?

  • Wobble
1 Like
2

Welcome to the community.

On the Framework-13, the keyboard is not usb. Like most laptops, it’s just a key matrix directly connected to the motherboard. Connector pinout. The Embedded Controller handles it.

On the upcoming Framework-16, the keyboard will indeed be usb connected and running open source qmk firmware on a rp2040 microcontroller within the keyboard module. Whether the input modules share a USB controller with other usb devices or ports I think is unknown at this point.

Framework has been posting Deep Dives about aspects of the Framework-16. There is one planned for the keyboard. The second Deep Dive was posted 2 weeks after the first. If they keep up that rate, you could calculate when the keyboard one will be posted, presuming they will be done in the order listed.

framework-laptop-16-deep-dive-180w-power-adapter

1 Like
3

Could you explain how it does that. I see from Qubes security mode that the USB, mouse and keyboard are [Unsafe] anyway.

So if USBs are unsafe what dif is there as there are USB ports to access

4

@MJ1 Thanks for the quick reply!
Making device everybody is happy with is an impossible task. Just a shame it’s something that “minor” in my case - maybe I gotta take another look at the 13 model.
Hope is still left though: Is the usb controller of the inputs (ie. primarily the keyboard but also touchpad) shared with the expansion ports?

@amoun

Device handling security | Qubes OS
I’d also recommend reading the architecture paper, which is a bit dated but still useful. I’m gonna try to explain though:

In Qubes, dom0 should be the only VM controlling the system. The USB controllers are contained by IOMMU to their own VM, over which you can then forward the devices: eg exposing them as block devices to other VMs or just passing them through. This is normally not possible to dom0 though, since that VM should not be exposed to anything external.
If an USB-controller controls the input, you (from the top of my head):

  1. increase the attack surface of dom0, which in its default state is as compartmentalized as possible
  2. increase the attack surface by potentially handling malicious devices exploiting USB kernel code (which is huge!)
  3. risk impersonation attacks by copying the keyboards ID
  4. and most importantly: if the USB controller is shared with the expansion ports, the same VM must handle them too. That means: if one USB controller has access not only to the keyboard, but for example also to a ethernet expansion port, suddenly that also could compromise the VM handling that controller, in turn compromising dom0 by intercepting the keyboards traffic. This does not require a malicious expansion, but could be an adversary exploiting a weakness in the expansion itself. This effectively worsens your protection from those threats even more than if you were using a bare-metal GNU+Linux, since the default configurations has passwordless root. Not using the other ports controlled by the controller is a high price to pay.

So the problem is not USB, it’s that your keyboard uses the same PCI device (ie. USB controller) as other devices. Qubes recommends non-USB based keyboards, such as used in the 13 model apparently.

If anybody has anything to add, feel free to do so. If I got anything wrong please tell me!

  • Wobble
1 Like
5

I don’t think it’s known yet for the Framework-16. I think I edited my post while you were writing your post. I noticed the message that you were replying. Not sure if you saw my edit.

1 Like
6

I haven’t, thanks for pointing it out!