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.
Conversation
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.
2
4
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
Having complex firmware with updates intentionally blocked isn't sane. At the very least users should have the option to install security updates fixing issues like remote code execution vulnerabilities. Known vulnerabilities in Wi-Fi, etc. are worse than theoretical backdoors...
1
1
4
Replying to
I don't have enough information to know if they're "gratuitously controlling what you can do with your own device" or "implementing a proper hardware security model where attack surface for alterring firmware has been removed". If the latter, it's a good thing in my book.
2
Replying to
I don't see how any attack surface has been removed and they've certainly prevented firmware security updates. Their goal is quite explicitly preventing the firmware from being updated through the OS, including going out of the way to have another processor upload it necessary.
But whatever, I'm not particularly interested in doing anything more than pointing it out and moving on at this point. I look forward to targeting some subset of open hardware RISC-V phones where it's not only actually open hardware but that doesn't come at the cost of security.
6
Replying to
The link was just about DDR training, which has nothing to do with the type of firmware you're talking about. The goal was to make the machine boot without having to run proprietary firmware on the main cpu, and their achieved it cleanly, with no tradeoff here.
1
Replying to
There is a substantial amount of proprietary firmware on the main CPU. They consider it fine because it's not set up in a way that it can be updated. I provided the link because it shows how far out of the way they're willing to go to prevent being able to update the firmware.
2
Show replies