I have heard and seen footage that the Pine phone’s kill switch’s do not work unless the phone is rebooted?
After the pine phone is rebooted the kill switches activate, but does this then mean that the Pine phones kill switch’s are software based rather than actual physical kill switch’s?
I thought the whole point of a kill switch, was that it worked instantly as it is a mechanical feature?
Can anyone confirm 100% that all the Librem 5 kill switch’s work instantly and without rebooting the phone or doing anything on a software level?
Has anyone else heard of this issue or have any info regarding it?
The relevant peripheral should have no power - so unless said peripheral deliberately contains a secret battery, it really can’t operate, and even if it can operate, that might not be useful to a malicious peripheral if the connection to the host has also been cut.
If you have the technical background (not saying I do), you can study the schematics of the Librem 5 for yourself and determine what you expect the behaviour to be.
Maybe someone (forum participant who has already received a Librem 5) can comment definitively that they have tested the kill switches and those switches work as advertised.
Since Purism laptops have had hardware kill switches for years, I wouldn’t expect too much uncertainty about the same feature in the phone.
I haven’t seen the schematics. But there should ideally be a setting from the mechanical switch that opens the power circuit to the given module, or second-best, that grounds a critical signal from the given module to the rest of the system. A mechanical switch that tells the software to disable the module isn’t really a hardware kill-switch.
So speaking of PinePhone switches:
SW1A - Modem - Pulls Q1501 gate up (FET killing modem power)
SW1B - WIFI/BT - pulls chip_en up (asks rtl to do something)
SW1C - OB/Mic - Breaks (disconnects) mic bias voltage from SoC
SW1D - R CAM - Pulls up PWDN on OV5640 (kind of S3 state)
SW1E - F CAM - Pulls up PWDN on OV5640
SW1F - Serial/Audio - pulls IN2 up on analog switch BCT4717ETB
Hello, I fully agree : @LinuxNew hello, what to say is very serious so please could you provide the source link referring to the Pinephone kill switches issue (need to reboot) ? Thank you
I am really interested to this phone, so if this failure is confirmed, it can become a serious trust issue from me regarding the privacy aspect of the Pinephone.
I had the impression that the switches on the Pinephone are a slightly different use case from those on the Librem 5.
You have to take the back off the Pinephone to change the switches and they are DIP switches, which makes me think that, yes, it is plausible that they are read once at boot time, but maybe that is fixable in software. (There might still be a delay in recognising the state change.)
Yes, they are more like those configuration switches/jumpers on motherboard or other pcbs.
So it’s more to configure hardware features of the phone (in cold state) rather than shut/unshut components/ports. On the other hand all of those features must be working without rebooting the phone as they either retain their hot state (S3 is minimum) or sit on hot-pluggable bus (eg modem).
When I flip a switch on my Librem 5, the relevant module disappears immediately (give or take a few seconds) in the software. If I flip the WIFI switch off, the WIFI icon disappears and lshw no longer shows it. Switching it back on brings the device back almost instantly and eventually the WIFI reconnects to the saved network and it is back. I haven’t actually broken out the multimeter to check that power is actually disconnected, but maybe I will soon.
The Librem 5 kill switches work immediately without rebooting the phone or anything (sometimes the software takes a second to detect and display the change though, it depends on where the polling interval is when you trigger the switch).
I routinely use the WiFi kill switch when I leave the house to save battery by having it be completely off and not scanning networks I pass by. I could do it in software too but it’s actually faster and more convenient to do with the HKS than going into Settings at the moment.
Not to mention the fingerprinting that is done of your phone if the wireless client device implicitly transmits the id of any AP that it is interested in associating with.
I guess the kill switches are for serious tin foil hatters because I personally won’t make much use of them. They’re not for everyone and some are going to make a big deal about how they work
I may misunderstand what’s going on with the pine phone, but my impression was that turning the switch off is instant. It cuts power to the peripheral, as wanted and expected. The issue is turning the switch on does not (reliably? vs ever?) reconnect the peripheral. This may be a software issue, where the dbus system or the kernel aren’t watching for new devices connecting on the integrated peripheral bus, or aren’t properly reinitializing a peripheral which died in an unspecified state. Or it may be a hardware issue, where the peripheral itself isn’t given power back properly, so hangs on reinitialization. If it’s a software issue, that can probably be fixed (might need to restart udev or something). If it’s a hardware issue, that kinda sucks, since the reboot time isn’t trivial.
On pine - only for modem and mic, for wifi and cameras it rather asks chip to stop working. And I suspect exactly to avoid re-initialisation issue (hw remains initialized, just enters powersave mode). So software should be able to pick it up after resume, but of course that feature may not yet be implemented in the kernel/userspace.
So if there is a backdoor in the WiFi and camera chip on Pine then it remains operating? Capture images on camera and transmit to bad guy via WiFi despite having operated the ‘kill’ switches?
Wifi yes, it runs own firmware so is a blackbox. I wasn’t even able to find consecutive answer what exactly the chip_en does, some references were pointing it merely disables BT, others that it drives entire chip into powersave.
Cameras - technically yes, the PWRDN signals the internal clock control to stop system clocks (but retain registers/ports) so technically there could be some backdoor signal to override pwrdn and re-enable the chip. Eg time sequence on reset line which controls the same subsys (that would need rogue kernel modeule). After all OV has own MCU inside.
A while ago I read that some modem, possibly the one used in the Pinephone, needed a 30 second delay to write stuff to flash/EE before power down. Otherwise one would risk bricking the modem.
I have searched for that post without finding it, did any of you read it too (or did I just dream this)?
If this is actually a problem, then the HKS will need additional circuitry. First assert the “shutdown, pretty please” signal, then cut power after sufficient delay. It’s a bit more involved, but certainly doable.
I don’t believe portable devices with removable battery will have such a design flaw. Because end user can always pull the battery from running device. If that bricks the modem - that’s a very bad component choice.
