Big difference between a device with components that are strongly hardened, highly audited and have good ongoing security support vs. the complete opposite. Also, portraying it backwards by misinterpreting how DMA / IOMMUs work is just wrong.
Conversation
Replying to
You can't claim hardware is secure you can't see the firmware for. Tomorrow's update could be hostile.
You present a fair argument though.
We either design to distrust the radios, or we might as well blindly trust their updates.
I am convinced here.
2
2
Replying to
Devices you're talking about have entirely closed source hardware and firmware. If you choose components that are known to be insecure and also don't apply fixes to known security vulnerabilities, backdoors are a non-issue, because you have the front door wide open to attackers.
2
You're also once again misrepresenting closed source software as a black box. It isn't, and in fact, if you're looking for malicious, hidden backdoors, I do not really see how you're any better off trying to find them hidden in source code vs. from the final assembly code.
2
Replying to
I want a future where I don't need to any closed code, and then rip out unauditable open code until the OS is something super lean and capable of being reviewed/trusted by the community.
Maybe this takes a decade.
Long term I feel we are screwed without this option existing.
1
Replying to
Auditing doesn't magically uncover all vulnerabilities, and you're talking about a vulnerability that was intentionally inserted and designed to be hidden, which means whoever did it had the opportunity to use all available tools to keep it concealed. They might actually be quite
2
happy if everyone uses reproducible builds since then they only have to target not just a specific compiler version or toolchain but a specific build environment. If you're auditing the source code for a backdoor, all of that stuff is attack surface for hiding a vulnerability.
1
The complexity of the language, runtime, toolchain, etc. is all part of the toolkit for this adversary making a hidden backdoor. There are plenty of vulnerabilities IN PLAIN SIGHT that are not caught by repeated audits and code review. If you use code that I wrote, you trust me.
1
Replying to
I am forced to trust you today but someone could threaten your family and force you to backdoor a critical target tomorrow.
I want to build towards a future where boundaries are well enough defined and code small enough that independent auditing can bring true confidence.
2
Maybe I am naive, but IMO we are in for a very bad time if we continue to build a world where a single coerced individual can backdoor an entire nation and easily get away with it.
I want to take any steps I can away from that.
Maybe we start over from the 80s :-P
1
Replying to
We are moving further and further away from simple systems.
A modern CPU is insanely complex and riddled with bugs and security flaws. It requires regular firmware/microcode updates to fix and mitigate these issues. Same applies to a GPU, etc. An SoC as a whole has so much more.
Replying to
Which is why projects like Betrusted are so vital. Dead simple RISC-V CPU on an FPGA and start over.
When a device like Betrusted can talk to radios in an safe/jailed way and do basic chat with a super lean and auditable base fw/hw story, I am happy.

