Then close off the attack surface to access these from untrusted domains. Installing new black boxes is not security hygiene.
Conversation
Replying to
There's a lot of work by others on improving isolation for these components and reducing exposed attack surface. I'm not particularly focused on security in this thread but rather frustration with projects falsely pretending to be open hardware or provide better privacy/security.
1
3
I don't understand how people can get away with presenting completely proprietary hardware / firmware as open. I'm sure it's even more frustrating for people doing the hard work of making actual open hardware, especially those trying to match current privacy/security properties.
1
6
Replying to
Absolutely. I share your frustration with misrepresentation of ARM SoCs as open, just not your enthusiasm for allowing post-shipping black box code in to replace one set of vulns with another, possibly-intentional set.
1
Replying to
It's not really a black box when it's not obfuscated and can be disassembled. The firmware signing keys for a lot of these things are also not controlled by the SoC vendor but rather the phone vendor and development boards can be obtained without keys burned into the fuses yet.
2
2
Being able to install firmware security updates fixing serious security vulnerabilities is important. Not being able to fix a remote code execution bug in the Wi-Fi radio or the GPU is a serious problem. Sure, the components should be isolated and usually are to some extent.
1
6
Having it isolated doesn't make the attacker gaining local code execution a non-issue though. There are direct consequences to these security vulnerabilities and it gives the attackers a way to compromise the rest of the device. It's a major step towards exploiting the OS.
1
1
Software including drivers is not generally written with much thought put into avoiding trust in the hardware. Hardware like the GPU is also assumed to enforce security boundaries. There's not much hope of that without security updates. It's complex and needs hardening / updates.
2
4
Components *should* also be designed without persistent state including not having any persistent firmware. It's a good thing to force it to be uploaded from the OS. It gets an extra layer of verification as part of verifying the OS, it's much less of a black box and is optional.
1
4
The main project that I'm referencing is taking things in the opposite direction. They prefer components with persistent firmware / state, which they prevent users from updating, and they've gone out of the way to make complex workarounds turning it into more of a black box.
1
3
See puri.sm/posts/librem5-. It's the approach being taken across the board. The proprietary hardware / firmware is still there, just set to be hard-wired with updates prevented, or uploaded via complex workarounds to avoid having it under the control of the OS and updatable.
I can't support hardware going out of the way to prevent security updates and various important security features. Outside of semantic games, it's less open. At the very least ship a fully unlocked device (fuses not blown, etc) and let people choose rather than forced insecurity.
1
A more open device would be one where you can purchase the device with fuses not blown so you can set your own signing keys for the low-level firmware or leave it in dev mode and install what you want, including the standard firmware security updates, or an open source rewrite.
1
1
1
Show replies