HCL - System76 Darter Pro (darp8) (2)

User Support HCL Reports
1

Remarks

System76 provides detailed instructions for physically removing or replacing certain components, so I:

  • Removed the Wi-Fi/Bluetooth module before powering on.
  • Disconnected the webcam/microphone connector before powering on.
  • Installed extra RAM (2 x 32 GB DDR4 SO-DIMMs @ 3200 MHz).
  • Installed an extra NVMe Gen4 SSD.

Qubes OS installation was a breeze.

In addition:

  • When I looked at the coreboot settings, I was surprised to see that Intel ME was enabled by default, so I installed coreboot-configurator in Pop!_OS to “disable” it (insofar as it can) with a simple toggle. This change was reflected in the coreboot settings afterward.
  • Suspend does not work on Qubes (presumably due to S0ix, but possibly compounded by disabling ME).
  • The HDMI 2.1 port doesn’t work with external monitors in Qubes, but it works in Pop!_OS. (Update: works with kernel-latest-6.0.12-1.)
  • The DisplayPort (via USB-C) port also doesn’t work with external monitors in Qubes. (Update: probably also works with kernel-latest-6.0.12-1.)
  • The MicroSD card reader doesn’t work.
  • Although coreboot states that the TPM is active, qubes-hcl-report does not recognize it.
  • The easiest way to update the firmware on System76 laptops seems to be via Pop!_OS, where there’s a built-in one-button update tool, so keeping the default SSD with Pop!_OS preinstalled seems useful. Since this laptop has two NVMe slots, I simply moved the default (slower) SSD to the slower Gen3 slot and used the faster Gen4 slot for my Samsung 990 PRO. This way, I won’t have to reopen the case the next time I need to use Pop!_OS to update the laptop’s firmware. Both OSes are independently LUKS-encrypted.

On the positive side, compared to my old ThinkPad T450s, this setup is noticeably faster, runs open-source firmware, and is not vulnerable to QSB-081.

Note: This is the second darp8 HCL report to be posted. The first one is here.

Attachments

---
layout:
  'hcl'
type:
  'laptop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  'unknown'
remap:
  'yes'
brand: |
  System76
model: |
  Darter Pro
bios: |
  2022-11-21_b337ac6
cpu: |
  12th Gen Intel(R) Core(TM) i7-1260P
cpu-short: |
  i7-1260P
chipset: |
  Intel Corporation Device [8086:4621] (rev 02)
chipset-short: |
  Alder Lake
gpu: |
  Intel Corporation Device [8086:46a6] (rev 0c) (prog-if 00 [VGA controller])
  
gpu-short: |
  Integrated Graphics (Iris Xe)
network: |
  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
memory: |
  65380
scsi: |

usb: |
  3
versions:

- works:
    'yes'
  qubes: |
    R4.1
  xen: |
    4.14.5
  kernel: |
    5.15.52-1
  remark: |
    <a class='ext-link' href='https://forum.qubes-os.org/t/16466'>read more</a>
  credit: |
    Andrew David Wong
  link: |
    https://andrewdavidwong.com/

---
3 Likes
2

Does this update tool need the Internet connection? If yes, doesn’t it break the security model of Qubes OS? If not, using a USB stick might also break the security model AFAIK.

1 Like
3

Yes, because the only (practical) way to download firmware updates is over the Internet.

I don’t know of any method of updating firmware that doesn’t break the security model. No matter what, you either have to download-then-install something in dom0 or bypass dom0 by downloading-then-booting from something that isn’t Qubes. If you have a better method, please let me know, as I’d love to use it. FWIW, not updating firmware also breaks the security model, because Qubes can’t fully protect you if the firmware its running on has unpatched security vulnerabilities. :man_shrugging: This simply seems like one of the least bad options.

4

But you shouldn’t have to use Pop!_OS for that, which has no network/USB/GPU/audio/apps isolation. You could do it in a Disposable, then verify the signatures in an offline qube, and then

  • boot Pop!_OS, insert a microSD with the firmware and perform the upgrade,
    or
  • (AFAIK it’s more secure) transfer the firmware to dom0 and install it there
1 Like
5

In theory, I would prefer your method, but I have trouble implementing it in practice:

Ok, downloading it in a disposable should be easy, since it’s just on GitHub:

https://github.com/system76/firmware-open

But which files, exactly, do you need to download? And do you need to somehow package them into a useful image after that? If so, how exactly?

How? I don’t see any PGP signatures, and even if I did, I haven’t been able to find any signing keys. (I just checked, and their git commits aren’t signed themselves and don’t have signed tags. I don’t see any detached signature files in the repo either.) My guess/hope is that it’s probably some signature scheme that I’m not familiar with that’s built into the tooling or coreboot itself.

But how will you tell the update tool to use the file from your MicroSD card instead of trying to download it from the Internet? Their documentation doesn’t hint at any possibility of doing this, and the tool itself doesn’t provide any options for anything like that.

But how can you install it in dom0? What would be the tool or app that does the installing, and what sort of input does it need? If I have to package or convert some raw files from GitHub into that useful input, how do I do that?

If we mess this up, we could brick the machine, right? So we need to be absolutely certain about what we’re doing, but we seem to be in the opposite situation here.

I did find this page, which describes flashing firmware via a USB drive, but it says that you can only use a special firmware file that you get directly from System76 support staff, so it sounds like it’s meant for older models that don’t have built-in firmware upgrading or for special troubleshooting cases or something.

Of course, I would never run any other apps in it, would disconnect all devices and peripherals before booting into it, and would use only wired ethernet. That takes care of pretty much everything except network isolation, which is still unfortunate, but still seems like the lesser evil so far.

At first, I got excited when I saw a section on updating firmware on other Linux-based operating systems, but it turns out the advice is just to use a Pop!_OS live disk. :frowning:

Maybe there’s a better solution here, but I don’t know what it is. Maybe @marmarek or @Demi know.

6

FWIW, as suboptimal as this firmware update situation is, it’s still better than the situation I was in with my ThinkPad. In order to update the BIOS on that, I had to download a file that I had no way of authenticating, use a Perl script that I had no way of authenticating in order to convert it into the appropriate image type, copy it onto a USB drive, then boot from that. At least now I’m not manually downloading all sorts of untrusted files and running scripts I found on the Internet to convert them myself. Instead, my downside risk is basically that, with respect to firmware updates, I’m in the same position as people who actually use Pop!_OS or Ubuntu as their main operating system (except it’s not even that, because I’m not using it for anything except firmware updates, so there are far fewer opportunities for the installation to be compromised.) Oh, and it was even worse once my ThinkPad stopped receiving BIOS updates entirely, since then I simply had no way to patch known vulnerabilities.

7

Thank you @adw for this HCL report, which is online now!

Also big thank you for posting a commit-ready HCL report, the first one (for me) ever. It’s not expected but highly appreciated!

1 Like
8

Jesus…

1 Like
9

The firmware update tool documentation gives some info on the verification process.

1 Like
10

You probably need to install kernel-latest for that.

I guess it has TPM 2.0, while the script checks for TPM 1.2 only.

It seems to be described at GitHub - system76/firmware-update: System76 Firmware Update Utility. The process seems to be rather complex to perform manually, but likely doable.

1 Like
11

Thank you both! I’m glad that my guess/hope panned out, namely that they do have a signature scheme that they seem to have put a lot of thought and effort into; it’s just one I wasn’t familiar with. Also, it sounds like the part about signature checking being built into coreboot itself isn’t there, but something adjacent sort of is? At least, that’s what I gather from this sentence:

The frontend runs the relevant flashing tools to update the firmware. These tools perform signature checking, but are binary and cannot be trusted.

Not quite sure what to make of that last part, though. I guess that means the use of that particular signature-checking tool wouldn’t be appropriate in dom0 or as part of the manual process of doing this.

Overall, after reading through this, I feel like my lack of knowledge (and the lack of detailed instructions for performing the steps manually) means that the risks of user error are probably higher than the risks of using Pop!_OS to do it.

12

The way I understand the documentation, you use the driver software to download and verify the firmware, and then you reboot the system into the firmware frontend which does the update.

The frontend is just a binary in /boot, which is why it can’t be trusted there is no way to know if it has been modified.