System76 Darter Pro (darp8)

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

usb: |
  3
versions:

- works:
    'FIXME:yes|no|partial'
  qubes: |
    R4.1
  xen: |
    4.14.5
  kernel: |
    5.18.16-1
  remark: |
    FIXME
  credit: |
    FIXAUTHOR
  link: |
    FIXLINK

---

Remarks

This machine is excellent! I don’t have many remarks other than that. When using i3 (not XFCE), I had to add 20-intel.conf under /etc/X11/xorg.conf.d/.

Also, a little bit of arandr (because I am not so good with xrandr), and I’m working actually with the laptop closed and off to the side! I went a little dangerous with some keyboard and mouse attached to dom0 since I’m in private places/non-dangerous for the most part.

Cheers!

Attachments

1 Like

I did notice while using a USB keyboard plugged in via USB SS10 (usb-c to usb-c), it “randomly” sends sys-usb processor to ~54%, and my mouse and keyboard are laggy. I couldn’t find anything exactly matching it on the forums that was helpful, so I’ll leave it here; there always seems to be a flood of control queue full errors:

# sudo journalctl -kb -xr -p4
Sep 09 10:32:55 fedora kernel: Booted with the nomodeset parameter. Only the system framebuffer will be available
Sep 09 10:32:55 fedora kernel: cpu 0 spinlock event irq 52
Sep 09 10:32:55 fedora kernel: cpu 1 spinlock event irq 57
Sep 09 10:32:55 fedora kernel: acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
Sep 09 10:32:55 fedora kernel: Grant table initialized
Sep 09 10:32:55 fedora kernel: device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
Sep 09 10:32:55 fedora kernel: hpet: Lost 1 RTC interrupts
Sep 09 10:32:55 fedora kernel: /dev/xvdd: Can't open blockdev
Sep 09 10:32:55 fedora kernel: db_root: cannot open: /etc/target
Sep 09 10:32:55 fedora kernel: piix4_smbus 0000:00:01.3: SMBus Host Controller not enabled!
Sep 09 10:32:57 sys-usb kernel: thunderbolt: probe of 0000:00:06.0 failed with error -110
Sep 09 10:32:57 sys-usb qrexec-agent[652]: PAM unable to dlopen(/usr/lib64/security/pam_sss.so): /usr/lib64/security/pam_sss.so: cannot open shared object file: No such file or directory
Sep 09 10:32:57 sys-usb qrexec-agent[652]: PAM adding faulty module: /usr/lib64/security/pam_sss.so
Sep 09 10:32:57 sys-usb qubes-gui-runuser[639]: PAM unable to dlopen(/usr/lib64/security/pam_sss.so): /usr/lib64/security/pam_sss.so: cannot open shared object file: No such file or directory
Sep 09 10:32:57 sys-usb qubes-gui-runuser[639]: PAM adding faulty module: /usr/lib64/security/pam_sss.so
Sep 09 10:32:57 sys-usb systemd[655]: PAM unable to dlopen(/usr/lib64/security/pam_sss.so): /usr/lib64/security/pam_sss.so: cannot open shared object file: No such file or directory
Sep 09 10:32:57 sys-usb systemd[655]: PAM adding faulty module: /usr/lib64/security/pam_sss.so
Sep 09 10:32:58 sys-usb systemd[879]: ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File system: 755 ConfigurationDirectoryMode: 555)
Sep 09 10:32:58 sys-usb kernel: kauditd_printk_skb: 87 callbacks suppressed
Sep 09 10:32:59 sys-usb alsactl[1135]: /usr/sbin/alsactl: load_state:1689: Cannot open /var/lib/alsa/asound.state for reading: No such file or directory
Sep 09 10:33:00 sys-usb pulseaudio[1359]: vchan module loading
Sep 09 10:33:00 sys-usb pulseaudio[1359]: using domid: 0
Sep 09 10:33:00 sys-usb pulseaudio[1359]: play libvchan_fd_for_select=19, ctrl=0x5f5b92fadee0
Sep 09 10:33:00 sys-usb pulseaudio[1359]: rec libvchan_fd_for_select=27, ctrl=0x5f5b92fae0a0
Sep 09 10:33:00 sys-usb pulseaudio[1359]: sink cork req state =1, now state=-2
Sep 09 10:33:00 sys-usb pulseaudio[1359]: source cork req state =1, now state=-2
Sep 09 10:33:00 sys-usb pulseaudio[1359]: Failed to open cookie file '/home/user/.config/pulse/cookie': No such file or directory
Sep 09 10:33:00 sys-usb pulseaudio[1359]: Failed to load authentication key '/home/user/.config/pulse/cookie': No such file or directory
Sep 09 10:33:00 sys-usb pulseaudio[1359]: Failed to open cookie file '/home/user/.pulse-cookie': No such file or directory
Sep 09 10:33:00 sys-usb pulseaudio[1359]: Failed to load authentication key '/home/user/.pulse-cookie': No such file or directory
Sep 09 10:33:00 sys-usb pulseaudio[1359]: module-rescue-stream is obsolete and should no longer be loaded. Please remove it from your configuration.
Sep 09 10:33:00 sys-usb goa-identity-se[1447]: GoaKerberosIdentityManager: Using polling for change notification for credential cache type 'KEYRING'
Sep 09 10:33:03 sys-usb kernel: kauditd_printk_skb: 2 callbacks suppressed
Sep 09 10:33:05 sys-usb pulseaudio[1359]: source cork req state =2, now state=1
Sep 09 10:33:05 sys-usb pulseaudio[1359]: sink cork req state =2, now state=1
Sep 09 11:33:00 sys-usb gnome-keyring-daemon[1597]: discover_other_daemon: 0
Sep 09 13:31:59 sys-usb kernel: hid-generic 0003:3384:0001.0004: control queue full
Sep 09 13:31:59 sys-usb kernel: hid-generic 0003:3384:0001.0004: control queue full
Sep 09 13:31:59 sys-usb kernel: hid-generic 0003:3384:0001.0004: control queue full
Sep 09 13:31:59 sys-usb kernel: hid-generic 0003:3384:0001.0004: control queue full
Sep 09 13:31:59 sys-usb kernel: hid-generic 0003:3384:0001.0004: control queue full
Sep 09 13:31:59 sys-usb kernel: hid-generic 0003:3384:0001.0004: control queue full
1 Like

The keyboard issue seems to be this:

also referenced here:

1 Like

Thank you @22kewbz0527 for your report, which is online now!

1 Like
---
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/

---

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

5 Likes

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.

2 Likes

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.

1 Like

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
2 Likes

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:

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.

1 Like

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.

1 Like

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!

2 Likes

Jesus…

2 Likes

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

2 Likes

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 · GitHub. The process seems to be rather complex to perform manually, but likely doable.

3 Likes

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.

1 Like

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.

1 Like

@22kewbz0527, how were you able to use an external monitor? I just got the same laptop, and unfortunately neither the HDMI port nor the DisplayPort (via USB-C) ports are working for me in Qubes. Did you have to download a newer kernel?

Maybe it was this part. Could you provide some detail about what you did?

(Update: Works fine after installing kernel-latest.)

1 Like