Hacker News Reader

Comment by Bluerise | Hacker News Reader

OpenBSD does not run on the rPi because there are only a handful developers taking care of the arm subtree, and none of them have time for it or are simply not interested. Heck, their whole arm subtree has been rotting and needs some major overhaul.

The main components of the new rPi are rather simple to get to work, so it's not a technical issue. The only real crapware inside is the usb controller.

I bet if someone supplied a diff they'd gladly take it. Also, I wonder why this rather old post is up here.

View on HN

Actually if you read the comments from the developers in that thread they won't support it until there is documentation on the firmware "blobs" you need to have in order to even boot.

I agree it is a fuzzy line but one which I happen to agree with.

There is a probably a thesis to be had for the first person to build a provably trusted system using untrusted base hardware. I am not even sure how you would start such a project.

> Actually if you read the comments from the developers in that thread they won't support it until there is documentation on the firmware "blobs" you need to have in order to even boot.

How exactly is that different to an undocumented or—forbid it—an unflashable BIOS? Don't even get me started on EFI...

Aside from coreboot, I don't really see anybody drawing the ideological-line-in-the-sand there when it comes to running their PC.

The difference is that the rPi blobs actually run on the GPU, the CPU is unharmed.

Still, both have access to the same memory. But that's a similar issue on the PC.

Well perhaps a better example might be System Management Mode on Intel CPUs, which easily allows for undetectable backdoors with constant access to the same physical memory as anything else running on the CPU.

I did read them. Now and a few months back. Janne raises concerns about running a blob on the CPU (which does not happen), while Stuart explains the boot stages correctly in detail and compares it to very similar issues on newer x86 technology.

It is a mischaracterization to say they have issues with the firmware, they clearly say they don't have the same objections to firmware running on the peripherals themselves.

The issue here is that the rPI requires driver code running inside OpenBSD that is a closed source blob.

I'm sorry, but that is wrong.

The main blobs are being run on the GPU, as bootloaders, even before the actual operating system is loaded. OpenBSD does not need to run _any_ blob itself.

There used to be a 3d graphics driver blob, but afaik that got open sourced. Also, if you don't do 3d, you wouldn't even need it.

So, to summarize, if somebody makes a port that doesn't use a blob, all is good. The question seems to be not so much if the blob runs before or after OpenBSD, but whether we would need to distribute it. If it's in the ROM, then this isn't even a question. But if it's something we are expected to write to the flash drive, that's a potential problem. Anyway, the question isn't very interesting given that the magic porting elves haven't yet gifted us with an OpenBSD RPi port.

I don't know exactly what the situation is. Don't care. I have a BeagleboneBlack if I wanted to watch the paint dry doing a build. :)

What's OpenBSD's policy on when something needs to be included?

The rPi boot process requires several files to be on a FAT partition on an sd-card: bootcode.bin, fixup.dat, start.elf, config.txt and the OS kernel; the first 3 of which are blobs.

Would those blobs need to be included, or would OpenBSD be fine saying "use your existing boot card, just drop in our kernel", or "go grab these files from https://github.com/raspberrypi/firmware/tree/master/boot when formatting the sd-card."?

If the blobs are preexisting that's less of a problem. But it also makes the hardware less interesting.

The blob runs on a different processor (the GPU), not inside OpenBSD.

But the GPU has access to the RAM.

So does the Hard Disk; see https://en.wikipedia.org/wiki/Direct_memory_access

Depends on how your firmware or OS sets up the memory protection hardware; see https://en.wikipedia.org/wiki/IOMMU

The same applies to the GPU. The rPi does not have an IOMMU, but most platforms OpenBSD supports do not have one either.

That said, based on other discussion here it seems this whole thread is a red-herring and there is no problem with the blobs, it's just that noone has written support for it.

If OpenBSD delivers the blob as part of their OS, they take moral responsibility for it (which, for good reasons, they don't want to take). On the other hand, you don't have to deliver a blob to support, say, a hard disk.

I agree 100% with the stance of not distributing blobs.

But you can put it on the user to provide it. A lot of linux distros have gone this route, if you want to boot debian on RPi you either need to create the FAT partition and put the blobs there yourself, or fetch a third-party image which includes them.

That's the mentality difference between mainstream GNU/Linux distributions (though Richard Stallman considers them as unethical and only endorses 100% free software distributions, such as Trisquel GNU/Linux (cf. [1])) and OpenBSD (for the OpenBSD mentality cf. [2]).

[1] https://stallman.org/stallman-computing.html

[2] http://www.openbsd.org/lyrics.html#39

you dont need to deliver any blobs, binary blob is a bootloader in rpi, once it loads you dont need additional blobs to run your code

To my understanding, no distribution of a binary blob would be necessary. It is already flashed onto the raspberry pi. The original drivers are open source but not free, but it would be easy to at least get vga working.

My knowledge is based on the rPi1, but cursory investigation suggests that this is also true on the rPi2:

There are several blobs that are necessary to be on the sd-card for boot: bootcode.bin, fixup.dat, and start.elf. Any bootable sd-card image for the Pi has them.

What's kind of interesting is that most of what start.elf is is actually an entire OS (ThreadX, I believe), that is running on the VC4 GPU in parallel to the OS on the ARM CPU; and that most of the Linux GPU drivers for it are just shims that send messages saying "hey, ThreadX, would you mind doing this for me?"

The open source driver does not run on the VPU.

And the bootloader had been reverse engineered (quite accurately, btw., although all the ISA mnemonics are totally made up). It should be possible now to rebuild it from assembly source.

My understanding of the boot process is that:

- the VC4 starts up and a ROM starts executing - the ROM loads bootcode.bin into the SRAM - bootcode.bin sets up the DRAM and loads the start.elf and fixup.dat - the start.elf sets up the ARM core and loads the Linux kernel

ARM code only starts executing at the last stage.

The only bit that's actually necessary on the SD card is the bootcode.bin --- everything else is under the control of whatever's in there.

They seem OK with BIOS, Intel microcode and other firmware on amd64 though.

They don't have to distribute it.

Yes, but that's not relevant in this context, which is about OpenBSD trusting binary blobs ("a provably trusted system using untrusted base hardware").

Reply on news.ycombinator.com