6 ms·

Raspberry Pi 2 Model B on OpenBSD

59 points by justinwr 11y ago

Bluerise 11y ago
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.
- ChuckMcM 11y ago
  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.
  - messe 11y ago
    > 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.
    - Bluerise 11y ago
      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.
      - messe 11y ago
        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.
  - Bluerise 11y ago
    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.
  - throwaway2048 11y ago
    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.
    - Bluerise 11y ago
      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.
      - tedunangst 11y ago
        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. :)
        LukeShu 11y ago
        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 https://github.com/raspberrypi/firmware/tree/master/boot when formatting the sd-card."?
  - tagrun 11y ago
    They seem OK with BIOS, Intel microcode and other firmware on amd64 though.
    - ghshephard 11y ago
      They don't have to distribute it.
      - tagrun 11y ago
        Yes, but that's not relevant in this context, which is about OpenBSD trusting binary blobs ("a provably trusted system using untrusted base hardware").
kbenson 11y ago
It's hard from this thread to determine if the OpenBSD developers have a point and are just expressing it unclearly, or if they are mistaken in some of their assertions and are unwilling to event engage on the issue enough to learn this. The one time someone references a prior rPi discussion, it's to a message from Theo De Raadt that says: Wow. Dream on. It is a mess of firmware. You know nothing of our history? I understand maybe this has come up before and they are tired of the discussion, but this is just toxic. Is it really so hard to just reference a valid prior discussion when this comes up?
- popalop 11y ago
  The OpenBSD mailing lists tend to be extremely Spartan. The guidelines users are expected to learn before using them generally involve (from most accepted to least accepted) Read the mailing lists. Read them again. If you have a problem read the man pages. If you still have a problem search the mailing lists for similar problems. Make sure you really understand your problem then search again. If after research you fully understand the problem but still don't have a solution post to the specific mailing list with diagnostic info. Consider writing up a bug report/ creating your own solution as necessary. and way way down the list, in the has virtually never been the correct thing to do category, is ask questions like "Will you support the RPi?" Those sort of questions have been asked for essentially every piece of hardware and subtechnology out there, and the answer is always either "No, because propritery whatever but you're free to do the work yourself" or "No, because we're busy and barely keeping the lights and servers on, but you're free to do the work yourself" or "Yes, and you'd know that if you read the mailing lists". The mailing lists are famous for their get sh*t done attitude and any information about posting on them will relay that to new users.
  - bootload 11y ago
    "The general guidelines users are expected to learn before using them generally involve (from most accepted to least accepted)" Back in 2003 running 3.2 on ancient hardware that is indeed the process I went through. [0] http://monkey.org/openbsd/archive/misc/0310/msg01026.html http://monkey.org/openbsd/archive/misc/0310/msg01026.html
voltagex_ 11y ago
Why has no one reverse engineered the boot blob on either Pi?
- wolfgke 11y ago
  How long is a piece of string?
  - joe_inferno 11y ago
    I'm unfamiliar with that rebuttal, but it sounds like it has significance. Could someone explain it to me?
    - voltagex_ 11y ago
      It signifies an unknown quantity, a string could be any length. I really don't like that saying at all.
      - SmellyGeekBoy 11y ago
        Also, it doesn't really make sense in the context of the question anyway...
  - deleted 11y ago
    [deleted]
  - ntoll 11y ago
    Twice the distance from the middle to one end...
- LukeShu 11y ago
  People are working on it. The biggest challenge is that it isn't "let's reverse engineer this ARM blob"--they have to reverse engineer the entire (VC4) architecture, and write an assembler for it. Most people think of the rPi as an ARM board; it's more helpful to think of it as a VideoCore IV board with an ARM co-processor tacked on. The stock "boot blob" isn't just a boot blob--it's actually an entire OS (ThreadX, I believe) that's running on the VC4 GPU, in parallel with whatever OS you load on the ARM CPU. Of course, you wouldn't need to re-implement all of the OS, but it does make reverse-engineering harder. The people working on this like to hang out at #raspberrypi-internals on Freenode. (Disclaimer: the last I looked into this was in January, before the Raspberry Pi 2 came out)
trengrj 11y ago
The Free Software Foundation has a good resource here https://www.fsf.org/resources/hw/single-board-computers https://www.fsf.org/resources/hw/single-board-computers on the "relative" freedom of single board computers. The "enforced" binary blob really turns me off the Raspberry Pi. I bought a BeagleBone black as you can actually boot them without non-free software. Recently BeagleBone's GPU manufacturer Imagination Technologies made comments that the PowerVR chip https://www.reddit.com/r/hardware/comments/37h2a9/i_work_for_imagination_technologies_mips_powervr/ https://www.reddit.com/r/hardware/comments/37h2a9/i_work_for... is planned to be open sourced. If this happens I hope a lot more people will switch over to the BeagleBone rather than head in the direction of cheaper and cheaper closed ARM platforms. For me, the promising part of these single board ARM computers is that we may escape from running untrusted binaries and avoid things like Intel's Management Engine.

59 points by justinwr 11y ago

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.

ChuckMcM 11y ago
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.
- messe 11y ago
  > 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.
  - Bluerise 11y ago
    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.
    - messe 11y ago
      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.
- Bluerise 11y ago
  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.
- throwaway2048 11y ago
  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.
  - Bluerise 11y ago
    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.
    - tedunangst 11y ago
      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. :)
      - LukeShu 11y ago
        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 https://github.com/raspberrypi/firmware/tree/master/boot when formatting the sd-card."?
- tagrun 11y ago
  They seem OK with BIOS, Intel microcode and other firmware on amd64 though.
  - ghshephard 11y ago
    They don't have to distribute it.
    - tagrun 11y ago
      Yes, but that's not relevant in this context, which is about OpenBSD trusting binary blobs ("a provably trusted system using untrusted base hardware").

kbenson 11y ago

It's hard from this thread to determine if the OpenBSD developers have a point and are just expressing it unclearly, or if they are mistaken in some of their assertions and are unwilling to event engage on the issue enough to learn this. The one time someone references a prior rPi discussion, it's to a message from Theo De Raadt that says: Wow. Dream on. It is a mess of firmware. You know nothing of our history? I understand maybe this has come up before and they are tired of the discussion, but this is just toxic. Is it really so hard to just reference a valid prior discussion when this comes up?

popalop 11y ago
The OpenBSD mailing lists tend to be extremely Spartan. The guidelines users are expected to learn before using them generally involve (from most accepted to least accepted) Read the mailing lists. Read them again. If you have a problem read the man pages. If you still have a problem search the mailing lists for similar problems. Make sure you really understand your problem then search again. If after research you fully understand the problem but still don't have a solution post to the specific mailing list with diagnostic info. Consider writing up a bug report/ creating your own solution as necessary. and way way down the list, in the has virtually never been the correct thing to do category, is ask questions like "Will you support the RPi?" Those sort of questions have been asked for essentially every piece of hardware and subtechnology out there, and the answer is always either "No, because propritery whatever but you're free to do the work yourself" or "No, because we're busy and barely keeping the lights and servers on, but you're free to do the work yourself" or "Yes, and you'd know that if you read the mailing lists". The mailing lists are famous for their get sh*t done attitude and any information about posting on them will relay that to new users.
- bootload 11y ago
  "The general guidelines users are expected to learn before using them generally involve (from most accepted to least accepted)" Back in 2003 running 3.2 on ancient hardware that is indeed the process I went through. [0] http://monkey.org/openbsd/archive/misc/0310/msg01026.html http://monkey.org/openbsd/archive/misc/0310/msg01026.html

voltagex_ 11y ago

Why has no one reverse engineered the boot blob on either Pi?

wolfgke 11y ago
How long is a piece of string?
- joe_inferno 11y ago
  I'm unfamiliar with that rebuttal, but it sounds like it has significance. Could someone explain it to me?
  - voltagex_ 11y ago
    It signifies an unknown quantity, a string could be any length. I really don't like that saying at all.
    - SmellyGeekBoy 11y ago
      Also, it doesn't really make sense in the context of the question anyway...
- deleted 11y ago
  [deleted]
- ntoll 11y ago
  Twice the distance from the middle to one end...
LukeShu 11y ago
People are working on it. The biggest challenge is that it isn't "let's reverse engineer this ARM blob"--they have to reverse engineer the entire (VC4) architecture, and write an assembler for it. Most people think of the rPi as an ARM board; it's more helpful to think of it as a VideoCore IV board with an ARM co-processor tacked on. The stock "boot blob" isn't just a boot blob--it's actually an entire OS (ThreadX, I believe) that's running on the VC4 GPU, in parallel with whatever OS you load on the ARM CPU. Of course, you wouldn't need to re-implement all of the OS, but it does make reverse-engineering harder. The people working on this like to hang out at #raspberrypi-internals on Freenode. (Disclaimer: the last I looked into this was in January, before the Raspberry Pi 2 came out)

trengrj 11y ago

The Free Software Foundation has a good resource here https://www.fsf.org/resources/hw/single-board-computers https://www.fsf.org/resources/hw/single-board-computers on the "relative" freedom of single board computers. The "enforced" binary blob really turns me off the Raspberry Pi. I bought a BeagleBone black as you can actually boot them without non-free software. Recently BeagleBone's GPU manufacturer Imagination Technologies made comments that the PowerVR chip https://www.reddit.com/r/hardware/comments/37h2a9/i_work_for_imagination_technologies_mips_powervr/ https://www.reddit.com/r/hardware/comments/37h2a9/i_work_for... is planned to be open sourced. If this happens I hope a lot more people will switch over to the BeagleBone rather than head in the direction of cheaper and cheaper closed ARM platforms. For me, the promising part of these single board ARM computers is that we may escape from running untrusted binaries and avoid things like Intel's Management Engine.