proposal: second qubes-certified laptop is Lenovo Thinkpad x220/x230

[mfc]

the second qubes-certified hardware should fulfill the following needs:

• laptop
• accessible used / second-hand
• cheap
• globally ubiquitous
• fulfills the System Requirements

I propose we choose the Thinkpad x220: it is the oldest Thinkpad x-series with VT-d (the x200 and x201 do not), all over the place used/refurbished, very inexpensive (~250 USD/EUR), portable, can be loaded with 16gb ram, and seems to have good compatibility: https://www.qubes-os.org/hcl/

All of the chipsets available for it (i5-2520M, i5-2540M, i7-2620M) seem to meet Qubes System Requirements: https://support.lenovo.com/us/en/documents/pd015812

It's worth noting this datasheet includes two other processors for the x220 without VT-d: https://shop.lenovo.com/ISS_Static/ww/wci/us/ww/pdf/X220_datasheet.pdf

I have looked online and not seen x220 advertised with these processors much -- the i3-2310M x220 I have seen online listed instead as the x220i, and the i5-2410M x220 seems to have been a smaller run (I don't see them being sold on ebay or NewEgg).

Still, if we were to choose it we would highlight on the page the compatible processors for the user to ensure they get an appropriate x220.

here is a tech-spec sheet with further details (TPM, etc):
https://www.lenovo.com/shop/americas/content/pdf/system_data/x220_tech_specs.pdf

I would be interested in others' thoughts!

[andrewdavidwong]

Cheapness and ubiquity are big pros, but I have two concerns:

• Recommending that users buy used hardware for Qubes runs contrary to some of the security advice we give (compromised hardware = permanent game over = throw out your laptop and get a new one).
• Does it have a TPM? The HCL cell is blue (unknown).

[mfc]

Yes it seems to have TPM 1.2 according to this official spec sheet: https://www.lenovo.com/shop/americas/content/pdf/system_data/x220_tech_specs.pdf

Compromised hardware could be new hardware as well as old. There isn't really a solution to "I want hardware I can trust" unfortunately.

[andrewdavidwong]

Compromised hardware could be new hardware as well as old. There isn't really a solution to "I want hardware I can trust" unfortunately.

New hardware and used hardware are not equivalent in this respect. To compromise new hardware, you have limited opportunities:

• Compel the manufacturer to cooperate
• Stage an interdiction operation
• Subvert the manufacturing process

All of these are risky and/or costly. Stakes are high. Being discovered would be a disaster.

To compromise used hardware, all you have to do is:

• Buy new hardware, compromise it, then resell it as used

The seller can pose as a random online merchant and can plausibly deny having compromised the hardware. ("It must have been like that when I bought it. I'm just a reseller.")

[mfc]

I agree with you (from a malicious individual reseller perpective), however used hardware can also be purchased anonymously/pseudonymously much more easily (Craigslist) if you are worried about state-level targeting.

These are issues for the individual to consider during the "buying things" process, it is ultimately the user's choice to buy things, how they go about it, what trust they have with the seller, etc. We are not compelling anyone to purchase anything, nor what method to do so.

I strongly believe that we should be listing/certifying a computer that fills all of those attributes I listed.

[andrewdavidwong]

Ok, sounds like a reasonable idea to me. It's true that we're not compelling anyone, but an official endorsement is significant. As long as we duly inform users of the security risks, I agree we should leave the decision up to them.

[tasket]

IIRC the x220 is very close to its T-series counterparts, the T420 and T420s (and probably the T520 too, although it has no HCL entry). Also Qubes was supposedly developed on the T420 and T420s. So I think those T models from that generation should be among the first to be added to the certified list.

[mfc]

just to update this, this may merge into #1594 and https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/ efforts and instead be a x230 (so positioning this for Qubes 4.0 certification).

on the surface only difference between x220 and x230 seems to be ~price and USB 3.0 ports (which may be worthwhile).

---

also would be nice to confirm if the laptop with coreboot could boot from sdcard for AEM (see related qubes-users thread).

[mfc]

hardware compatibility

To permanently enable middle button scrolling for x220/x230, create the following script in your dom0 home directory:

sudo vi start_trackpoint.sh

#!/bin/sh
xinput set-prop “TPPS/2 IBM TrackPoint” “Evdev Wheel Emulation” 1
xinput set-prop “TPPS/2 IBM TrackPoint” “Evdev Wheel Emulation Button” 2
xinput set-prop “TPPS/2 IBM TrackPoint” “Evdev Wheel Emulation Timeout” 200

Make it executable:

sudo chmod +x start_trackpoint.sh

And a file to execute it on boot:

sudo vi /etc/xdg/autostart/ibm-trackpoint.desktop

[Desktop Entry]
Type=Application
Exec=/home/[USER]/start_trackpoint.sh
Terminal=false
Name=IBM Trackpoint
GenericName=IBM Trackpoint
StartupNotify=false
Categories=System;X-Xfce-Toplevel;

modified from https://www.peerlyst.com/posts/evaluating-qubes-os-as-a-penetration-testing-platform-andrew-douma

[tasket]

AEM seems to be a compat tripping point right now. How compatible are these models with the latest AEM w/ tboot 1.9.4?

See issue #2155

[Jarwolf]

I read this whole page and found it very interesting. I am wanting to have a Laptop that works with Qubes. I have an Windows MSI ib shuxh u play games and such on, which is out of the equation. I have an HP notebook of some sort and has Windows. I am currently installing it on here abd had to boot the USB from UFI i think it was. It was the only way to actually to get it to install. Now' previously, It asked for the 'disc password' on the boot up og Qubes. As soon as I woukd hit enter after inserting my password no moe then 5 seconds later, the laptop shuts down. I can't afford 1500 on a laptop...Honestly, just spent the last 600 i had on bills and a ham radio, so yep...im keeping my fingers crossed that this will work this time around.

[mfc]

just to add a potential argument against the x230, in order for the USB qube to work one has to set pci strict reset to false, which is a security risk. Setting USB controller to USB2.0 only in BIOS is insufficient. When I have some more free time I will do a reinstall on a Heads/coreboot machine and see if I have to set this to false on that machine as well.

[reconmaster]

With a refurbed x230, 4.0 installed reasonably well. Only issue with default lenovo firmware was sys-net. Subsequent research suggests coreboot can resolve this, and I'll be trying libreboot over xmas. I suspect this may be related to @mfc point about pci reset flag.

I'd say if providing support for these older comps, it would probably be pragmatic to focus on those supported by open firmware. Given the risks incurred with the ME, securing the hardware stack should align with Qubes' mission statement. Probably a disclaimer about dangers of low-level threats should at least accompany them where ever they end up in the docs.

[andrewdavidwong]

Assigning to @rootkovska and @marmarek to decide.

[tlaurion]

I contribute to the Heads adventure for 2 years now since I realized the limits of libreboot, RYF hardware and QubesOS compatibility for people requiring the most free x86 hardware available, supporting QubesOS requirements and having strong beliefs that privacy should prevail in this surveillance era when being out there, in the world.

Since then, I started an enterprise called Insurgo Technologies Libres / Open Technologies in 2017, beside being a security trainer. I did this in the goal of being able to propose trustworthy hardware to the most vulnerable customer base, right defenders and journalists. I also offer KGPE-D16/KCMA-D8 desktops/servers for QubeOS support, but this is not the subject here.

I've been in the network security world for more then 15 years now, and I believe things need to shift if we want things to really change. Libre hardware is a goal, alternatives to x86 are popping up, but security though compartmentalization is still the best approach by untrusting everything, and QubesOS is not planning to support x86 alternatives anytime soon. The need for trustworthy hardware is palpable now at every level.

I've already secured:

• Discounts on bulk buys for x230/x230t/x220/x220t models from a trustworthy refurbisher. Visited his installation. Saw how he works. Had a couple of laptops shipped to me and resold to close customers and security trainers partners. The hardware looks and feels brand new and can be customized before being shipped. Standard x230 specs are:
  • 2.9GHZ i7
  • 16GB DDR3 ram
  • 240 GB SSD drive
  • IPS screen
  • Backlit keyboard
  • Webcam
  • Atheros AR5B95 wifi card
• GPG2 support in Heads is ready to merge, permitting Nitrokey Pro/LibremKey RSA4096 and newer cipher support and reseting the SmartCard to factory defaults.
• cryptsetup-reencrypt is included in the rom, empowering the user to reencrypt his OEM preinstalled QubesOS installation. Integrity of dom0 packages and template installation can be validated from a simple rpm -qa|xargs sudo rpm -V command if desired.

Work applied on refurbished laptop before shipping to/training users:

• Validate Windows 10 boots (Validate hardware is ok)
• Flash latest BIOS updates from Windows.
• Open up hardware casing. Inspect for tampering (no X-ray here though). Extract both SPI flashes externally and store them on provided microSD card.
• Apply me_cleaner on 8MB extracted SPI flash rom which contains Intel ME, trimming modules other then ROMP and BUP and setting AltMeDisable bit
• Reflash cleaned Intel ME externally on the 8MB SPI flash.
• Flash externally Heads x230-flash on 4MB SPI flash.
• Flash Heads internally with FBWhiptail support in (same Puri.sm GUI)
• Own TPM with diceware based passphrase. (Insurgo owns the hardware at this point)
• Own Nitrokey Pro/LibremKey (admin and user passphrases). Insurgo owns the GPG card at this point.
• Generate keys on the Nitrokey Pro/LibremKey. Incorporate public key into rom for boot configuration signature validation.
• Install latest QubesOS release in a LUKS container with diceware generated passphrase.
  • QubesOS latest release is provided on a MicroSD-to-SD-to-USB3 card reader adapter optionally, permitting to access the microSD card in read-only. The microSD card also contains SPI flash backups in option, or the files are given back to user over chosen secure communication channel.
• Create a user "user" with another generated diceware passphrase.
  • Both passphrases are provided through user preferred secured communication channel.
• Deploy recommended settings and default templates and qubes. No updates. This permits to use rpm to validate integrity of mostly everything from dom0 if desired.
• Deploy additional templates/clone templates to deploy additionally user desired softwares/ user defined qubes/ desired customizations.
• Sign boot configurations with Nitrokey Pro/LibremKey.
• Generate new HOTP firmware integrity attestation, stored inside Nitrokey Pro/LibremKey.
• Reboot and validate NitroKey Pro/LibremKey flashes green, attesting firmware integrity.
• Ship NitroKey Pro/LibremKey and computer hardware seperatly with tracking information with signature requirements upon reception.

On reception, user needs:

• To power up the computer with Nitrokey Pro/LimbreKey inserted. The key should flash green, attesting firmware integrity.
• To reown the TPM, factory reset the Nitrokey Pro (through GnuPG from Heads) and change user and admin passphrases to his own.
• To summon cryptsetup-reencrypt from Heads to reencrypt LUKS container with his own choosen passphrase.
• To define a default boot option (should be the first entry, which will change when the AdminVM is updated by the user), enter his previously choosen TPM passphrase, a new secondary LUKS passphrase that will be promoted to enter at every boot (different then LUKS recovery passphrase), which uses TPM measurements as a seed and stores the result in LUKS slot 1. (LUKS encryption passphrase is stored in slot 0)
• To change his QubesOS user password on first boot.
• Enjoy.

Things still needing to be done:

• Work on salt recipes to deploy necessary features not currently being included into Qubes. Unfortunately, i'm not a salt wiz. Any help welcome.
• The most important missing salt recipe concerns the possibility of deploying a second AdminVM, accessible through a tor hidden service.
  • That feature would empower users 3rd parties/IT departments/me to offer remote support to clients. The outcome of this would be beneficial to the whole QubesOS community and ease mass adoption.
• Partnership with Puri.sm for faster LibremKey shipments since from the US. (3 weeks delivery for Nitrokey requires stocking.) The call with them will happen after Christmas. : waiting for final quote.
• Adapt Whiptail to guide the user in hardware ownership required tasks. (Whiptail menu for: TPM reownership, Nitrokey/LibremKey reownership, key generation and key and trustdb inclusion in rom.) : done

Let me know what would be the next steps to comply to the certification process @mfc @tasket @andrewdavidwong @marmarek. I'm not a big player and don't have a lot of funds, yet. But this could be scalable with a bit of help.

• Would QubesOS/ITL/FSF/FPF be willing to play the role of escrow/moderator under OpenBazaar? Know an entity that could play that role?
• Else. What merchant platform would satisfy most vulnerable users needs for zero logging? Someone has expertise at that level?

On a side note, I want to reform the structure of my enterprise to form a cooperative when good allies will be found to sit on the board with me. The goal being to reduce costs and have others trusted trainers and technicians to remote assist user base. I'm ready for mass production and waiting for the next steps to make it happen in collaboration with you guys.

[andrewdavidwong]

Let me know what would be the next steps to comply to the certification process

I'm not sure what you meant to link to, but take a look at this, if you haven't already:

https://www.qubes-os.org/doc/certified-hardware/#hardware-certification

[tlaurion]

@andrewdavidwong exactly that. Edited previous post.

[andrewdavidwong]

@andrewdavidwong exactly that. Edited previous post.

Ok, then please proceed as described there.

[tlaurion]

@mfc

just to add a potential argument against the x230, in order for the USB qube to work one has to set pci strict reset to false, which is a security risk. Setting USB controller to USB2.0 only in BIOS is insufficient. When I have some more free time I will do a reinstall on a Heads/coreboot machine and see if I have to set this to false on that machine as well.

This is untrue if booting from coreboot/heads.

@tasket :

AEM seems to be a compat tripping point right now. How compatible are these models with the latest AEM w/ tboot 1.9.4?
See issue #2155

SINIT requires some blobs to be extracted from original rom and present in coreboot to be able to support AEM. From a Heads perspective, booting from an external USB drive is not a problem at all once that is figured out. I started the work but i'm stuck and waiting for @zaolin. See this Heads issue

[mfc]

hey all, given the Insurgo PrivacyBeast came out, there is now a certified laptop based on globally accessible/source-able hardware should someone want to make it themselves, or buy from Insurgo. so I am closing this ticket.