Hacker News new | past | comments | ask | show | jobs | submit login

The RPi has several proprietary binary blobs required for it to function, and always has. This has been one of my long-standing gripes about the platform’s security.



Unfortunately, there are no boards on the market (that I know of) that don't have any closed-source blobs. Also (unfortunately) it is probably going to stay this way because of legal requirements.

1) Broadcom has quite a bit of stuff they want hidden and don't allow any of their many customers (including the Pi) to open-source.

2) The Pi 4's SoC has a hardware H.264 block and hardware H.265 block. Older Pi's had a hardware MPEG-2, hardware VC-1, and hardware H.264 block. These blocks require royalties and are _heavily_ protected by MPEG LA. If open-source software was released that could control these blocks, you could possibly expect a huge lawsuit against the Raspberry Pi Trading arm.

3) To the Pi's benefit, the VideoCore is not open-source but is the most openly-documented GPU available in a mobile device. Most Pi competitors use Mali, which if you look at Hackaday's Pine64 Un-Review, works with almost nothing and has wretched documentation. There is some open-source work, but quite a bit remains closed or completely inoperable on Linux.

4) If you need platform security, look elsewhere. The Pi doesn't support secure boot, licensed code signing requirements, and the new Pi 4 allows almost anyone to update the USB and SoC EEPROMs just by putting in a new SD card and running a few commands.

5) Cortex-A72 on Pi 4 is venerable to Spectre.


>These blocks require royalties and are _heavily_ protected by MPEG LA. If open-source software was released that could control these blocks, you could possibly expect a huge lawsuit against the Raspberry Pi Trading arm.

I think you're confusing copyright and patents. Just because some technology is patented, it doesn't mean it can't be open sourced.


True, it could be open-sourced, but the RPT would no longer exist after the lawsuits are finished.

Edit: Even if the RPT wrote their own firmware, not from Broadcom, and released it, they would still risk being sued to pieces for patent violations galore. After all, if you license H.265 alone, there are over 1,100+ pages in the Table of Contents alone just listing all of the patents worldwide on it.

Edit 2: And they could be possibly sued by Broadcom for violating the IP sharing agreement used for developing the chip by developing an open-source blob software.


The first sale doctrine might save them.

If I buy your patented thing from you, that exhausts your patent rights for that copy of the thing. If I modify it, and do something you don’t like with it, you can’t come after me under patent law.

Note that I didn’t say anything about contract or copyright law—they may have signed something saying they wouldn’t reverse engineer the chip, or the sale could come with an end user Eula to that effect.


You're assuming RPT would write the firmware. There's no reason that has to be the case.


You can find open-source firmware attempts by the community, but they haven't gotten much farther than booting the Pi.

I'm just saying that if RPT tried to write their own firmware, they could be in big legal trouble, so I wouldn't expect any open-source firmware from RPT anytime soon.


Also, be advised, that a one-line sed -i crack (open source software) is widely available for the bootcode of pre-4 Pis that universally enables the hardware codec blocks without a license.

It is “heavily protected” only in a legal sense, not a practical one.


Could you perhaps elaborate on what Broadcom wants hidden, and precisely why? I have always wondered about the specifics of those things.


Broadcom isn't really against anyone making their own firmware (and people have tried, but haven't gotten much further than booting). As for the parts that can never be open-source:

1. The decoder blocks, H.264 and H.265, Broadcom/RPT can never release the source code to this without violating potentially thousands of patents worldwide.

2. The GPU of the Pi runs a ThreadX RTOS, which is licensed, runs on "billions" of devices worldwide, and can never be open-source without being sued for, well, huge amounts of damages. (The GPU blobs will never be open for this reason, but perhaps a mostly-complete GPU firmware NOT based on ThreadX will be released someday by the community, but I wouldn't hold my breath).

Also, you know the Pi's new OpenGL driver? All it does is convert the OpenGL commands and stuff into commands for this proprietary ThreadX GPU software.

3. If you think this isn't great, it's still better than the Pi's competitor boards, which have missing gaps in functionality, proprietary blobs which don't work well or even at all, and open-source implementations that currently just suck. (Read Hackaday's Pine64 Un-Review to see what I mean. It's improved a bit since then, but this is why "Pi-killers" haven't caught on.)


Interesting. Thank you so much for the reply! Would it be feasible to engineer an open source firmware that doesn’t support any of the things you listed?

I use Pis as a stateless platform for an application that doesn’t use any graphics, GPU, or codecs. I imagine several other people do too.


> Also, you know the Pi's new OpenGL driver? All it does is convert the OpenGL commands and stuff into commands for this proprietary ThreadX GPU software.

You mean the old driver? The new one is based on Mesa.


At least some of the Orange Pi boards don't require any blobs (if you ignore the boot ROM - which isn't user replacable in any case, and that's probably a good thing since it improves brick resistance). The open source drivers for the hardware video decode and graphics are a little bleeding-edge and require a very recent kernel and libraries though.


The Orange Pi uses Mali Graphics, which _may_ (I'm not certain) have a proprietary RTOS on it.

I do know that The Raspberry Pi has a RTOS for the VideoCore GPU, and it is based on ThreadX RTOS, which is proprietary and used on "billions" of devices. The RPF will never be able to make that OSS.


I'm optimistic about the OLinuXino boards from Olimex. They're certified open source hardware by OSHWA, with all the bootloader code, schematics, and even CAD files on Github. I think the Mali firmware is the last holdout, but with the new Lima and Panfrost drivers landing in Linux we may soon have replacements for that too.


For (4) do you know of where else to look? Is there a board with a Pi-like price that does support trusted boot, or some sort of TPM-like remote attestation?




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: