Sorry if this has been answered already but I couldn’t find any such discussion. Empirically, I get the sense that this is a GPIO pin that tells the OS (via ACPI) to please disable the wifi/camera/mic ASAP. It’s not actually sitting on the power rails ready to disconnect one of those devices immediately, the way that hot(un)plug PCIe would actually work. I get this impression because, at least from my experiments, it kills USB devices as well, which is desirable but would be impossible in the latter case because they’re not directly connected to PCIe. Ideally, it would kill these devices via the power rails and then also send a notification via ACPI that a virutal GPIO had been flipped, so therefore it’s time to kill their USB equivalents as well. That would decrease the shutdown latency for the vast majority of users simply because most of us don’t have duplicates hanging off USB.
Correct or not, I notice pretty massive latency when turning off the wifi. At least on L15, there’s a multisecond window of time between flipping the kill switch and actually losing the connection, which is plenty of time for some disaster or attack in progress to wreak further havoc. Not sure if this can be improved (because it probably comes down to the OS vs hardware speed) but I thought I should mention it, if nothing else then to suggest the above hardware tweaks for future platforms.
This is an interesting question. We should check what these kill switches do, with a multimeter and follow the wires just to be sure (although mike and webcam run into the lid assembly/display bezel on the librem 15)
This might be related - on this thread I provided a video of defective device where hardware kill switch no longer kills.
Purism offered RMA for defective device to review it and are waiting for me to get it sent to them. Random crap in my life and travels keeps getting in the way and it’s been a few months and defective device is not shipped to them yet, as it happens. Maybe soon.
Edit: Basically, if we assume HKS is actually software switch and can fail to kill, and US govt probably made it that way and made Purism and it’s all some kind of lie, to be honest I still use Librem 5 all the time, I like to dance the dance of living this lie because it is a lesser lie than living the lie of using Android, and of that I am quite convinced simply by how I feel using Purism tech
Obviously, it would be much harder to check those kill switches in the case of a Librem 5.
So I guess, we have to take what Purism claims at face value if not verifiable. On the other hand, this would be a fraud; so, bad for reputation and possibly even legal proceedings - would a company like Purism really risk this? The term “hardware kill switch” itself is not ambiguous: it is not software activated neither any kind of poke into a GPIO register: a physical switch will disconnect or short something.
When I have some time, I will check this on my L15 MBD and report my findings if any.
Nice video!
My only negative remark would be that upon reassembly, the thermal paste should have been entirely removed, and new paste reapplied. Otherwise you could have dissipation problems sooner or later…
Such insightful feedback above! I see that I’m not alone in my perplexity over what, exactly, these switches are. Here’s a test:
Connect to wifi using your onboard module.
Make an audio call to someone using a chat app.
You say “one”. They say “one” only after they hear you. You say “two”, etc. Do this as rapidly as possible, ideally with a friend in the same town.
Disconnect the wifi using the HKS.
Suppose you say “five” just after flipping the switch. Can you get a reply from them before you lose the call? If you can then it’s sure as hell not hitting the power rails and draining a receive buffer; the OS is waiting to notice a GPIO transition.
No, I don’t think Purism is a scam, which implies malicous intent. But this could be a design flaw because somebody forgot to account for OS response latency, so they imagined that GPIO is good enough (and to be fair, it’s faster than having to move the mouse around and click on the wifi settings). But let’s see someone try the above experiment first. I’m personally not in a position to do so due to the latency induced by my network perimeter.
I made a call between matrix on phone to matrix on PC, but headset on, so that I hear matrix voice better and … what should I tell?
HKS microphone cut voice instantly with the very little network delay.
HKS WiFi cut voice in same manner.
Dlonks story is not interesting in the way “HKS is software switch”, but rather in “can HKS fail killing?”. As I showed, the data stops being collected at the moment I use the switch. The OS has a recognition delay, but sensors are already off.
I’m a bit late to the party here, but yes this is generally the cause of KS activation delays.
The Wi-Fi kill switch relies on PCIe hotplug (support for connecting and disconnecting PCIe devices while the system is on). We kill the power to the card, which causes it to suddenly disappear from the bus. For USB that’s normal, USB devices get plugged/unplugged all the time. For PCIe, while it is supported, it is not very commonly used.
IMO, PCIe hotplug tends to be less polished than USB. It works and is supported, but card drivers probably aren’t tested with it as much, so they’re not polished to detect and report card removal in any condition. They might wait for transactions to time out even though the card is now gone, for example, before eventually noticing that the card is gone.
Is there a way to “open source” confirm as users? For example, I heard someone tell me the Librem 5 uses a small circuit board to make decisions when the HKS are flipped, which forwards those decisions to the system. That way it can have special rules, such as “turning off all 3 switches will turn off GPS, even though there is not a GPS switch,” or something like that. Putting a decision network of wires between the switch and the cutting of power… is a bit of a weird accusation. That’s some hearsay from me. Why live off of hearsay? Where would we look to find truth? I think the L5 disassembly video linked by Frankly is a good example of this.
It’s a few chips. It seems to be using an AP2281 load switch for cutting the power.
The schematics have been published. You can see for yourself how the HKS cuts power and how the three HKSs are combined to turn off the sensors (including GPS).
So then the ultimate answer is that PCIe devices are killed immediately so they can’t record further incoming data (even if the drivers hang around displaying active wifi/mic/camera icons for a while), and USB devices are killed whenever the OS gets around to propagating the message over to them, so they can in fact continue recording for a while. Correct me if I’m wrong @jonathon.hall@irvinewade .
If my understanding is correct then maybe you can’t do much better, so Purism deserves credit for that.