Recently I took a glance at L5 schematics and was a bit surprised to see how kill switches are implemented. I don’t have any questions about microphone switch - it seems to be a pretty straightforward solution. However, I was suprised by WWAN implementation: the kill switch works essentially by driving the W_DISABLE pin low instead of cutting the power from the wireless module. By mPCIe specification,
In normal operation, the card should disassociate with the wireless network and cease any further operations (transmit/receive) as soon as possible after the W_DISABLE# signal is asserted. Given that a graceful disassociation with the wireless network fails to complete in a timely manner, the Mini Card shall discontinue any communications with the network and assure that its radio operation has ceased no later than 30 seconds following the initial assertion of the W_DISABLE# signal.
So, even if the card respects the specification, it may stay active up to 30 seconds, which is probably not what expected by the end user from the “kill switch”. But if the card hardware/software is not trusted (i.e. it may violate the spec in some very special conditions like if (asked_to_spy_by_nsa) { ... } and stay active even when W_DISABLE is low), nothing prevents it physically from continuing its operation. It still stays powered and connected to the system.
WLAN seems to use the same approach.
So, the question is: why it is considered reliable to ask the wireless cards “could you please be so kind and stop working?” instead of just cutting the power from these cards or, at least, disconnecting the antennas from the cards in addition to lowering the W_DISABLE pins?
Yes. @licryco i am assuming that you looked at the schematics of the devkit. Considering that we have not yet released the final schematics of the Librem 5.
The Hardware Kill Switches in the Librem 5 work in a different way from the devkit. The HSK do cut the power to the wifi and other items in the Librem 5. So it’s not just “asking kindly”.
We will release the schematics of the Librem 5 as well.
I’ve question about kill switches: using PureOS, a Debian derivative, that we can manage/check/modify “easily” throw source code, why to implement physical switches (that raise the price of the L5) instead of SW switches that’d have same effect?
L5 doesn’t use close software like Android or Apple.
Hope make sense for you my question
For the cell modem the reason is that the firmware is proprietary and thus we can’t be sure what it does when told nicely to turn off. For example the modem may still maintain a connection to the cell towers allowing the cell provider to track your location.
I believe wifi/bluetooth cards may also have a similar problem.
These also allow greater certainty that even if the phone is hacked into, these pieces still can’t be slealthily still on. Main concern being the mic/camera there.
Whether you consider those worth the extra protection is up to you and your individual threat profile.
Consider malware that transmits your audio/video to some interested party. Just because your OS is OSS, that does not mean there can never be malicious software on your phone. And that is not to speak about the trust in the hardware components that live a life of their own in your device. Yes modem, I am looking at you!
Many devices that I have worked with in the past have had the ability to draw running current from a driven port pin that is set as an input and is pulled externally to a logical high state which can also (unintended) source current in to the device. I have seen this happen several times on different devices. There have been times when running an IC where I scratched my head and asked myself “how can this device possibly run with VDD dis-connected?”. I have never followed-up to test in those instances, whether grounding VDD stops the device or not. But when I find the correct port pin and disconnect the logical high to it, the device will abruptly stop.
Some devices can even draw running current from a driven oscillator pin alone. This isn’t a rule, but more of a semi-common anomaly in some IC chip devices. Hopefully the hardware kill switches in the Librem 5 were actually tested under several different operating conditions. This may seem to be unnecessary to some people. Applying stimulus to IC pins without having a specified VDD applied first is usually a bad idea. Some PCB-level hardware application designers count on the device not working without an applied VDD.
Most devices don’t sustain damages if you apply stimulus to other pins while the device is powered-down. You can always lower the number of hardware components or lines of required code in your application in most cases by ignoring the universal rule that says to never apply stimulus to a device pin without applying VDD to the device first. But most often, the device with a detached VDD will at least run impaired to some degree if it does run.
None-the-less, I have witnessed accurate code execution and ADC conversions and the corresponding delivery of accurate 12-bit ADC data to port pins from an MCU with no VDD applied on a few occasions. The first time I saw it happen, it kind of freaked me out a bit. You stand back and say to yourself, “what I am seeing is impossible”. Then you troubleshoot, just to figure out how this impossible thing can be happening. In silicon, not all current paths in a circuit are always simulated in the design phase. Especially the undesired modes are not tested. After all, no one is going to complain to the semiconductor manufacturer about the device operation in any condition wherein a VDD is not applied.
Typically in most applications, you would always leave VDD applied when the application is running and then use the “Enable” or “not-Enable” pin to turn the device on or off as the application runs. The only guaranteed way to prevent a device from operating is to disconnect not only VDD, but to also remove all stimulus including any driven oscillators. However, application testing could validate whether or not any stimulus to the device causes the device to work without a VDD input.
Even a car with an empty gas tank will run for as long as you continue to spray ether in to the carburetor. The engine requires fuel and doesn’t care where the fuel comes from.
Back in the 80’s I remember a 1200 bps modem model that would run off the power of the land line’s dial tone. The phone company didn’l like that. Future models had a power supply. (It was blue.)
Then there is the classic issue of powering down a disc abrubtly (especially a spinner). You didn’t want your application writing at that moment. With today’s SSD speed and protections for sudden power loss there is enough latency to finish the write in most cases.
Too bad most cars are fuel injected and carburetors have become rare. I have to junk an old car that has a cracked fuel injector. Costs me more to fix it it is worth. It still drives but one smells the fumes at a stop sign. I determined to take it to the place where it gets weighed and you get money for the metal when it gets low on gas. (It had a full tank when the mechanic diagnosed it.)
Has Google found the Librem5 flaw yet?
Wednesday March 8 around 3:00 pm I say, “I need to buy some mustard.”
Wednesday March 8 around 4:00 pm I am forced to use Youtube because I can’t find an essential video on Peertube.
I open Youtube: the first video that appears is a mustard commercial. I freak out. The microphone of my Librem5 was closed (kill switches), I checked. The mic on my Librem 14 was also closed I’m sure. I thought it was just the NSA that could get through that protection… I’m pissed! Is there any other explanation? Could I have been triangulated by the Android cell phone of the person who was with me and the lap top of my co-worker in the next office?
If I understand correctly, you also use a GAFAM and you never found that they could have heard you despite your closed kill switches? I’d feel better if it didn’t happen to anyone else. It would show me that it was really a coincidence.
Someone say that :
" But for me that is not enough. What about the other sensors in the phone? What stops someone using the speakers as a microphone, or stealing information from the accelerometers? For that matter, couldn’t the accelerometers potentially be used as a microphone? Is there an ambient light sensor, or a proximity sensor? And if so, will the power to them get cut too?? " Kill switches, but what about the other sensors?
