If you open the sys-net Qube Settings from the Qube Manager, then select the Devices tab, what is listed in the Selected section on the right?
01:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
Why?
1 Like
The wireless network controller is not present in my sys-net Qube Settings. I had Qubes installed on an ssd in my Librem 13 and put that ssd in my new Librem 14. Everything else works. Thankfully the ethernet network controller is present and ethernet works. I tested PureOS before swapping the ssds, and Wifi did work on the Librem 14, so I do not know why it does not show up in Qubes. I thought the wireless was the same in the older and newer Librem laptops so it should not need drivers or anything. It should work, right?
Does anyone know what I need to do?
Should I click the button that says “Configure strict reset of PCI devices” in the sys-net Qube Settings? Could that possibly cause me issues with my currently working ethernet connection?
1 Like
Solved
I had to boot the Librem 14 with the Wifi killswitch disabled (allowing Wifi device to be powered on) in order for it to show up in the sys-net Qube Settings as an attatchable device. Then I could see it and attach it the sys-net Qube.
The Wifi killswitch on the Librem 14 behaves differently than the Wifi killswitch on the Librem 13. On the Librem 13, I could start the sys-net vm with the killswitch enabled (blocking Wifi device) and use the killswitch to change states while the sys-net vm was still running. On the Librem 14, if I attempt to start the sys-net vm with the Wifi killswitch enabled (blocking Wifi device), I get an error that the sys-net vm could not start because the Wifi devices was not attached (even though the ethernet device is attatched). And if I enable the killswitch (blocking Wifi device) while the sys-net vm is running, the sys-net vm goes from 0% CPU to 50%-60% CPU, and switching the killswitch back to allow the Wifi device does not make the Wifi device re-attatch.
Could someone from Purism (or someone else that understands this issue) comment on why the Librem 14 behaves this way?
2 Likes
This is because on L14 the killswitch kills power to the WiFi card completely and on L13 it just asks WiFi card to shutdown.
1 Like
Thank you for the information. I am glad that it all works now and have confirmed the killswitches work properly.
1 Like
Hi @dom0. Did Qubes work out of the box, or did you perform any configuration? Is it 4.1? In the first case, could you please help with providing one more HCL report for Qubes OS? Some people say it requires tinkering. This could help to put Librem 14 in the short list of compatible devices.
1 Like
Hi @fsflover. I just submitted a post on the Qubes forum post you linked. Thank you for suggesting that I do that.
2 Likes
In the Librem 14 using the the Hardware Kill Switch for the wifi/bt results in the whole device to disappear from the PCIe bus.
To quote one of our team members:
Because it disappears from the PCIe bus entirely, Qubes reports that error, because it has assigned that PCIe device to the sys-net Xen VM
and it looks like Qubes isn’t handling the situation where a PCIe device disappears, gracefully, compared to, say, USB devices disappearing
3 Likes
Hi guys, so what I understand from the above, is that starting Qubes in the Librem 14, we need to boot the laptop with the wifi switch on, to enable wifi, if we intend to use wifi. Ok, just one question, and please forgive me, as I am still learning, and pretty new to linux/unix, and Qubes. I have no ethernet connection at current address, so I have no choice but to use wifi, so I have to boot my Librem laptop each time with the wifi enabled. Immediately after booting, I will enter my disk encryption passphrase to first unencrypt the disk, before then entering in my user password.
Ok so my question is this:
Does having my wifi on, while I am writing these sensitive passwords, cause them to be exposed at all to the outside world?
Ideally I would like to enter my passphrases, especially the disk unencryption passphrase, while I am not connected in any way to wireless or the internet, to keep them secret.
So does having the wifi on (or at least enabled) at boot, therefore cause these passphrases to be exposed at all to the outside world, while I am typing them in?
And if so, is there a workaround that anyone could suggest, to improve the security?
(eg I guess I could boot with the wifi enabled at boot, but then quickly turn the wifi off, before entering my disk encryption and user passphrases, then turn the wifi back on again after that. But from what I have read, turning the wifi switch off at all, will keep it off for that whole session, so that won’t work either…)
Appreciate any feedback or ideas, or even guidance on this matter.
Thank you. I really appreciate any feedback.
I think that this is a theoretical possibility, but I have not seen any information about it. It is definitely not something for average people like you and me to worry about.
Out of curiosity, I did some testing when I first received my Librem 14 and wrote about it in my QubesOS forum post here (this is the new link since the page was moved):
In case that was confusing:
-
Boot computer with Wifi disabled.
-
When the grub menu disappears and the screen goes black, flip the killswitch to enable the Wifi.
-
Once the Qubes luks decrypt screen appears, you can flip the killswitch to disable the Wifi.
-
Type your password, hit enter, and then flip the killswitch to enable Wifi.
-
Once the user login screen appears, you can flip the killswitch to disable Wifi.
-
Type your user password and hit enter.
This way, you can type your passwords while the Wifi is disabled, if that makes you feel more comfortable.
Hi dom0
Thanks for your reply. Thanks for taking the time, and sorry my slow reply. I just wanted to keep playing around with it, to see if I could indeed get it working as described, or to see what would work for me.
ok just for feedback, in case it helps to inform anyone else.
ok I tried playing with the hardware wifi switch, turning it on and off, as recommended. Unfortunately it did not work for me.
It seems to me, that the hardware wifi switch MUST be ON, throughout the whole boot and startup and login process, until the SYS-NET qube has fully established itself. I think if the hardware switch is off at ANY stage before the sys-net qube is fully started, then sys-net will not detect and attach the PCI Device (Wireless card) during its startup process, and so there will be no wifi at all.
My only concern really, was that with the wifi hardware switch enabled, so that wifi is enabled and on, that decrypt and login passphrases could be leaked out via the enabled wifi.
However, I think now that this is not possible.
Because, until the sys-net qube starts, (after all those passphrases have been input) the PCI Device (wifi card) is not even attached to the sys-net, and there is therefore NO networking functionality (or even networking icon shown in top right hand corner tray). So at the time of entering and typing in the decrypt and user passphrases, there is no wifi functionality at all, even with the wifi enabled on the hardware switch. The wifi functionality only happens AFTER sys-net starting up and the networking icon and functionality starting up.
I do remember there were bugs before in the intel chip, (the Spectre bug?) where entered passphrases that were still held in memory or ram, could be accessed and copied out by malware (I think it was the Spectre or maybe Meltdown bug? - sorry, can’t remember now), so this could a security vulnerablity - BUT, Purism has patched this, I remember reading somewhere, so that these bugs cannot access passwords stored in memory now.
So, even typing in passphrases in at startup, should have no security vulnerablities at all, as far as I can see. (Although I am always happy to learn and be corrected, if anyone has superior knowledge).
ok I just thought I would post this, in case it helps to ease anyone’s mind.
But yes, to recap, I found the hardware switch must have wifi enabled throughout the whole startup and login process, and that turning that switch off at any time before sys-net has fully started, will result in no wifi.
But once the sys-net has started, and the network icon appears, THEN the network can be disconnected, and the hardware switch turned off for wifi. Then if it is switched on again, just restart sys-net, and wifi networking is working again. But you do have to restart sys-net.
ok hope this helps someone else who may have had same issues.
Thanks for reading.
T
This is only true if you have sys-net set to autostart on boot. I should have mentioned that I do not have any qubes set to autostart. You can use this command to see whether or not a qube is set to autostart:
qvm-prefs sys-net autostart
For my use, I have created panel buttons to start and shutdown all of my service qubes. I have a sys-net qube for ethernet networking, a sys-wifi qube for Wifi networking, a sys-usb qube for usb management, a sys-usbnet qube for usb networking, a sys-audio qube for audio management, and then sys-whonix and a few firewall qubes. There is a lot of customization that can be done in qubes. I prefer my system to boot as quickly as possible, allowing me to decide exactly which qubes boot and when.
To create my start and shutdown buttons, I made launcher items in the panel that execute a script for the given function, and the script is just the qubes command to start or shutdown the qube:
qvm-start --quiet sys-net
qvm-shutdown --wait sys-net
You could also input the command itself instead of using scripts, but I use scripts in order to make restoring backups easier.