Hacker News Reader

Comment by kiba | Hacker News Reader

it has now been made clear that the phone will have to use proprietary firmware blobs for a variety of onboard devices.

They worked with the FSF to make it certified. To my understanding, it's basically an impossible tasking to write open source firmware, not if you want to throw additional million of dollars(this is just a guess).

The compromise is that you basically cannot update those binary blobs.

View on HN

It was always my understanding that some of the hardware would not be open, but that hardware would be sufficiently isolated from the core of the device.

I think that is the key design aspect, since as other user stated, it is extremely difficult to get open source firmware unless you are willing to spend a lot of $$.

It is indeed a sad state for Purism 5 to be in.

Agreed, having modems not sharing memory with the CPU would already be a big progress.

It's nice, but not enough. Modem will still have access to a lot of things, like all unencrypted communication, all metadata, content of all regular calls and SMS, etc.

It's nice that it can't control other devices in the SoC, but that's of little value. Modem, given it's connected over USB can also immitate any other USB device, including keyboards, pointer devices, storage devices, display devices, etc. and actually control the UI.

It can even try to exploit Linux USB stack/drivers by providing specially crafted USB messages to less used/tested USB drivers.

It's somewhat disappointing people repeat this thing about direct memory access as the only way modem can attack the device. It's not nearly enough to use USB. A lot of other mitigations are needed, if you don't trust the modem.

I raised a concern about USB isolation about a year ago, both about the modem launching a fake USB attack and potential issues with USB peripherals via the USB C port. The underlying issue is that, unlike bluetooth, USB devices are approved and enabled automagically by the kernel.

In general this is desired since you really want your USB keyboard to work on system setup, or you can't do anything with the computer (unless, like me, you have a PS/2 keyboard). Also, the USB device gets initialized by the BIOS/UEFI on a typical computer, which means it could launch an attack before the kernel is even loaded.

Good news is neither you nor I are the first to spot this problem, and there is already a project which adds authentication/pairing for USB to the linux kernel. It doesn't solve the boot-time issue, but it does solve the USB stick (or USB 3g/4g card) pretending to be a keyboard+hdmi monitor issue.

It's already in Linux

https://www.kernel.org/doc/html/latest/usb/authorization.htm...

Sadly, the modems are on PCIe, so this means they are sharing memory and address space with the host iMX8.

You can use an IOMMU to isolate DMA to a separate security domain. This is how Qubes OS works.

No iommu on the imx8mq.

That's unfortunate, since an IOMMU is an excellent solution to this kind of problem, especially when one considers all the potential Linux USB stack vulnerabilities that can be exploited if you assume the modem is untrustworthy.

Sadly, you're wrong, and the phone modem is on the USB bus precisely for that reason.

Sadly I am happy to be corrected! :D

Yea, if feels like if you wanted that kind of isolation, you'd actually need a second SoC on there with its own memory and some kind of communication back to the main processor.

When I was working in the mobile industry, I was told repeatedly that a 100% FOSS phone would be impossible. Not only is the existing tech proprietary and patent-encumbered, even if somehow you could get past that your GSM radio must be certified before going to market. And if your radio is FOSS-based that means an end-user can toy with the baseband, therefore you will never get your cert, period. The stuff at the lowest level must locked down before being allowed on a public mobile network.

You can release reproducible signed builds that the user can verify. You can be open source without allowing users to upload new blobs.

You can still accept PRs and stuff.

This is what caused me to totally dump nvidia. Their new cards require signed drivers to enable boosting behaviour, and they are unwilling to build and sign the nouveau driver. It's not like it's hard to set up a buildbot...

I wonder if you'd have to recertify after each pr merge

You would need to certify each signed release. Most likely, you wouldn't make a signed release for each PR, because of the time and expense involved, until you got to the point were changed were few and far between.

No, just before actually releasing it. Nobody cares about the code as long as it is not running on the devices.

I have no idea why anyone expected it any other way, even laptops need firmware blobs for the WiFi. (there are, I think two (2) WiFi cards with the beginnings of open source firmware for them, mine is actually one of them and I've taken the time to read through it. Lots of stuff is still totally unimplemented (a couple of popular encryption standards being the deal breaker for me personally.))

Reply on news.ycombinator.com