+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone (https://forum.pine64.org/forumdisplay.php?fid=120)
+--- Forum: PinePhone Hardware (https://forum.pine64.org/forumdisplay.php?fid=122)
+--- Thread: Hardware killswitch alternative (/showthread.php?tid=9720)
Hardware killswitch alternative - deckaddict - 04-22-2020
I've seen several threads that has mentioned that the kill switches are a bit hard to reach and awkward to use in a smooth way. At the same time I understand that it is an added complexity in the manufacturing process to make them external.
My suggestion.
As a user I can in principle not verify that the kill switches work but have to trust the hardware manufacturer. So I wonder if it would be possible to instead have a LED solution that can show if the HW is disabled, these LED's can be assembled in a way that software can not turn them on/off without also impact the power mgmt to these components.
The good things with this is that it can make it possible to use software switches instead which can be very easy and convenient.
The drawback is of course that there would be need for extra hardware drivers specifically for this device, but maybe it can be worked into some sort of standard.
There are many details to figure out here. For example it is important that the software can not control when the LEDs are turned on at all, so either they are constantly lit or there is one external test button that can be used to check the state to ensure that the software can not turn on/off only before showing the LED state.
Just wanted to share the idea.
RE: Hardware killswitch alternative - Dendrocalamus64 - 04-22-2020
Malware with a Pinephone module could briefly turn on the GPS to sample location, briefly turn on the wireless to do a squirt transmission of the most important harvested data and download queued instructions, monitor the system state and wait for a good opportunity when there hadn't been any user input for a while and you likely weren't looking at your phone. It would need to have an audible beep or buzz, and lock the LEDs on for long enough to be noticed.
The switches need to be external and robust enough to enable and encourage regular use. It's more work, but it's the only right way to do it.
RE: Hardware killswitch alternative - wibble - 04-22-2020
(04-22-2020, 01:33 PM)deckaddict Wrote: I've seen several threads that has mentioned that the kill switches are a bit hard to reach and awkward to use in a smooth way. At the same time I understand that it is an added complexity in the manufacturing process to make them external.If you don't trust the manufacturer to wire up the hardware switches as they say they do then why would you trust them to wire up the LEDs as you want them?
My suggestion.
As a user I can in principle not verify that the kill switches work but have to trust the hardware manufacturer. So I wonder if it would be possible to instead have a LED solution that can show if the HW is disabled, these LED's can be assembled in a way that software can not turn them on/off without also impact the power mgmt to these components.
The good things with this is that it can make it possible to use software switches instead which can be very easy and convenient.
The drawback is of course that there would be need for extra hardware drivers specifically for this device, but maybe it can be worked into some sort of standard.
There are many details to figure out here. For example it is important that the software can not control when the LEDs are turned on at all, so either they are constantly lit or there is one external test button that can be used to check the state to ensure that the software can not turn on/off only before showing the LED state.
Just wanted to share the idea.
In practice you can verify that the hardware modules no longer respond to the kernel you supply when the hardware switches are off. Depending on skill level you may be able to inspect the board and test voltages on pins to see that it is wired as promised.
RE: Hardware killswitch alternative - deckaddict - 04-22-2020
(04-22-2020, 05:04 PM)wibble Wrote:(04-22-2020, 01:33 PM)deckaddict Wrote: I've seen several threads that has mentioned that the kill switches are a bit hard to reach and awkward to use in a smooth way. At the same time I understand that it is an added complexity in the manufacturing process to make them external.If you don't trust the manufacturer to wire up the hardware switches as they say they do then why would you trust them to wire up the LEDs as you want them?
My suggestion.
As a user I can in principle not verify that the kill switches work but have to trust the hardware manufacturer. So I wonder if it would be possible to instead have a LED solution that can show if the HW is disabled, these LED's can be assembled in a way that software can not turn them on/off without also impact the power mgmt to these components.
The good things with this is that it can make it possible to use software switches instead which can be very easy and convenient.
The drawback is of course that there would be need for extra hardware drivers specifically for this device, but maybe it can be worked into some sort of standard.
There are many details to figure out here. For example it is important that the software can not control when the LEDs are turned on at all, so either they are constantly lit or there is one external test button that can be used to check the state to ensure that the software can not turn on/off only before showing the LED state.
Just wanted to share the idea.
In practice you can verify that the hardware modules no longer respond to the kernel you supply when the hardware switches are off. Depending on skill level you may be able to inspect the board and test voltages on pins to see that it is wired as promised.
If you don't trust the HW manufacturer you can't use anything. And sure you can use different technology to check it but I was more thinking about an on-the-go solution that you could trust.
RE: Hardware killswitch alternative - deckaddict - 04-22-2020
(04-22-2020, 02:39 PM)Dendrocalamus64 Wrote: Malware with a Pinephone module could briefly turn on the GPS to sample location, briefly turn on the wireless to do a squirt transmission of the most important harvested data and download queued instructions, monitor the system state and wait for a good opportunity when there hadn't been any user input for a while and you likely weren't looking at your phone. It would need to have an audible beep or buzz, and lock the LEDs on for long enough to be noticed.
The switches need to be external and robust enough to enable and encourage regular use. It's more work, but it's the only right way to do it.
True, what if the LED got lit every time they were enabled by software and then a latch held it lit until you reset it with a hardware buttom.
Makes me think that maybe it should just be two RGB led's that can be lit in different patterns for what is on/off and then the hw control can be a specific button combo like double tap on power. Sure then you risk toggling through an unwanted state for a second.