I'm very interested in the OpenBSD OS, as it currently seems to me to be the option that takes security more seriously than its contemporaries. But as I was reading about it, it occurred to me that even if OpenBSD is all it claims to be, how does all that security and openness matter, if I'm running the OS on closed-source BIOS/proprietary hardware?

I am aware of Open BIOS, coreboot and Libreboot, but I wonder why security-focused systems like OpenBSD don't make such a big deal about using open firmware. Don't you defeat the purpose of open security by using closed firmware in the first place?

  • 43
    You appear to be equating "open source" with secure. Closed source code can also be secure. Your question will also depend on what you want to secure against and what open source code gives you in your scenario that closed source does not.
    – schroeder
    Commented Mar 11, 2016 at 16:37
  • 2
    Yes, I do equate openness with more security. I'm not sure if this is a "right" stance in the tech security field or more of "philosophical" one. I just figure that if anyone can look at your code it's harder to get away with something malicious, like in Lenovo's Superfish case, and you don't take the promise of security just at word value. So yes, openBSD development might indeed be of a very high standard, but isn't the fact that it's open that guarantees that it indeed is of a high standard? As "anyone" can look for themselves?
    – herzEGG
    Commented Mar 11, 2016 at 17:20
  • 11
    Just because a bunch of people CAN look at something doesn't guarantee they will; it also doesn't guarantee disclosure of any vulnerabilities they've found. So, open source doesn't guarantee more safety and security, it simply facilities the process that COULD lead to more safety and security. Commented Mar 11, 2016 at 18:13
  • 14
    @herzEGG Being secure by virtue of being open has been disproven many times, most recently by the openSSL project.
    – Andy
    Commented Mar 12, 2016 at 0:53
  • 3
    That's why we need open hardwares.
    – ferit
    Commented Mar 13, 2016 at 8:03

11 Answers 11


Historically, the open source movement is not about security but about freedom. Basically, Richard Stallman was very dismayed at not being able to fiddle with his printer because the driver source was unavailable.

OpenBSD's stance on being "secure" does not come from it being open source, but on an avowed goal and pledge to do things properly with regards to security (still historically, OpenBSD came into existence because some developers in NetBSD were much better at programming than at managing human-to-human peaceful relations).

The association between security and open source is more recent. In fact, right from the start, it was explained as being an incomplete concept (see Ken Thompson's famous Reflections on Trusting Trust). One element in the discussion is Linus's Law that says:

given enough eyeballs, all bugs are shallow

The core idea is that, with sufficiently many reviewers, bugs will be found, and this extends to security-related bugs. This holds, however, only on the premise that there are reviewers. Open-source software makes external reviews easier, but that does not mean that external reviews actually happen. When was the last time you went through existing source code ?

Case in point: OpenSSL. After yet another vulnerability was found in the code base, a fork was made, called LibreSSL, and they started an explicit reviewing effort, that found several serious issues in the code base. These issues had been there for years, right in the middle of a library which can be said to be one of the most crucial security-related libraries in the Linux ecosystem. So this was open source, and yet not sufficient (at all) to achieve proper vulnerability detection.

So of course open-sourceness helps with security, but not as much as can be hoped for.

What open source really brings is a much increased risk for people who want to willingly plant backdoors. It is hard to make code that looks innocuous to reviewers and still does bad things (there is a contest for such code).

  • 2
    I appreciate the link to The Underhanded C contest! Commented Mar 11, 2016 at 18:32
  • 1
    I think the freedom aspect and security are inter-related. It's true what you say about openSSL and the bugs not being discovered. But if OpenSSL were closed, the ability to fork it is zero. Also, with closed source software you simply have to trust whomever wrote the code. With OSS, you can examine the code for how transparent it is. You don't necessarily have to even find an actual exploit, just merely count "WTF's per minute". I don't think any of the major browsers chose to use OpenSSL, possibly for this very reason. Commented Mar 11, 2016 at 20:26
  • 3
    Richard Stallman has little to do with open source. He promotes free software. These are different things. Commented Mar 13, 2016 at 11:31
  • 1
    RMS used to be "against" security in many of the ways it's conventionally understood today, believing that every user of a multiuser machine should be an administrator: lists.debian.org/debian-devel/2002/09/msg01810.html
    – pjc50
    Commented Mar 14, 2016 at 9:22
  • 1
    @JamesSnell In that rare case, the trust is merely placed on another 3rd party, the code reviewer. The code reviewer has an inherent conflict of interest here, since they're paid by the company who produced the source. Also, if a company gets a "bad review", they can just shelve it, and pay someone else for a better one. Commented Mar 14, 2016 at 15:55

Open Source Does Not Unequivocally = More Secure/Safe

Anyone CAN look at open source software/hardware, but that doesn't guarantee that "anyone" WILL look at it; further, if they do look at it, it also doesn't mean that they will disclose something that they find that could be a vulnerability. People assume too much about open source, and one of the fallacies they believe is that if a bunch of people CAN look at something that it's all of a sudden safer and more secure. This isn't unequivocally true. It's nice to be able to have a lot of eyes on the product, but the ethics and morals of those eyes are of concern to me as much as their technical prowess is.

That being said, there are many benefits of open source if the concept behind it is implemented properly.

Also, closed source doesn't automatically = less secure/unsafe.

But to directly answer your question, no you don't automatically defeat the purpose of using a known OS that is concerned with security like OpenBSD by running it on top of closed source hardware as the hardware itself could have very secure code/firmware behind it just as much as something open could.

  • 6
    Also, color me stupid but I feel like it's common sense that it's harder to find security holes in software that you don't have the source code for than in one that you do... which is not meant to be used as an excuse in improper settings, but which is realistically true.
    – user541686
    Commented Mar 12, 2016 at 5:31
  • 5
    There was OpenSSL, where probably lots of people looked at it, and then looked away in disgust, with very little actual reading and understanding the code done, until the shit hit the fan.
    – gnasher729
    Commented Mar 12, 2016 at 13:08
  • 2
    This post completely avoids the issue of trust. Even if the firmware is secure, who can say it only does what it claims to?
    – Sqeaky
    Commented Mar 12, 2016 at 19:57
  • 1
    @Sqeaky: Even if it's open-source and secure, who's to say the hardware is doing what it's supposed to?
    – user541686
    Commented Mar 12, 2016 at 23:50
  • 1
    At least you know it's not backdoored... I think you understand the question of OP wrong.
    – ferit
    Commented Mar 13, 2016 at 8:05

Leaving aside the "open source == secure" argument, you can also look at this question as "Why run a secure OS when the BIOS/firmware isn't guaranteed to be secure".

Why bother locking my front door when an attacker can just break the windows?

You will never make a completely secure system. What you can do is make sure you work on securing the parts that are easy for an attacker to exploit. It is a lot more work to make firmware exploits, and they are limited to targeting a certain model of hardware. Whereas an OS bug is easier to exploit and affects a larger target base.

So yes, ideally you want both, but having just one isn't useless.

  • Is it also worth mentioning that firmware exploits often require physical access, at which point your "secure" firmware can be replaced or tampered with. Commented Mar 14, 2016 at 12:23
  • 1
    The threat models and avenues of attack are different. A better analogy would be "why bother locking my front door when I could get mugged on the way to the store?". Having insecure firmware won't make you less secure to, say, an ffmpeg bug anymore than being vulnerable to being mugged makes it not worth it to lock your doors. They fix totally different problems.
    – forest
    Commented Apr 5, 2016 at 1:58

Open source (free/libre) software is not (primarily) about security. One of its more important aspects is trust: you can verify what's running, it is much harder to hide something malicious. Some people also claim to more people will (might) be reading the code, which means chances are higher of vulnerabilities being found and fixed, resulting in higher code quality. This was already discussed in the answer of Tom Leek in depth. I won't get into this debatable topic deeper in this answer, as your question is not about why open source software is more secure, but why bothering at all if the firmware is closed source.

Putting aside the fact that also open source software is not necessarily secure, will running trusted code on untrusted firmware not make code execution untrusted? Sure! But the attack vector is potentially smaller. It is much harder to access the device's firmware interfaces than accessing your computer's operating system and application software, which might even be providing services in the internet (and lots of other interfaces to complete strangers). There will never be full security, but you can try to minimize risk within a given budget.

With adequate effort, closed source (UEFI/BIOS) firmware can be replaced with open source software: Coreboot is a great example which implements an open firmware for some products. But the UEFI/BIOS is not the only firmware: BLOBs like Intel's management engine sometimes are still required, hardware devices like graphics and network cards have firmware, your hard disk has, there is even microcode loaded to the CPU. And all of them have more or less arbitrary control over memory and/or storage. Finally, you might even distrust the CPU vendor, who might implement malicious circuits in plain hardware.

You have to stop at some point, and simply trust the vendor, as costs heavily increase the deeper you descend the stack towards hardware. Do you have the capability of finally verifying a complex CPU design and manufacturing the CPU on your own?

At Chaos Communicaiton Congress 2015 (32C3), there was a great talk how to get Towards (reasonably) trustworthy x86 laptops, providing a summary on the topic.


There is no such things as full security, but one can make it harder to break security. While it would be possible to compromise the system from inside the BIOS, UEFI, Intel SME, BIOS of the network or graphic cards, CPU Microcode, bad CPU design... this is considerably harder than to use a bug in a user space program or the OS kernel. Thus the OpenBSD guys care about the problems they can solve and which really help. This does not mean that they are not aware of the other problems.

  • I'm a layman to the degree that I must look up what the UEFI spec allows; but indeed, compromising a system through the mainboard firmware seems totally trivial (the UEFI specifies network access at boot time). That code would simply be part of the product, placed there by a government agency, nosy company or malicious employee (or all three) at production time. This has apparently been done by the NSA with Cisco products, keyword Jetplow. And the NSA is part of an elected government. Commented Mar 14, 2016 at 7:48

There are always deeper levels to consider, and users have to choose where to stop.

  • Many chips have an unflashable firmware / BIOS. Do you want that, even though you could never edit it?
  • What about the microcode of your processor? That can be replaced (and is)
  • What about the uneditable microcode of your processor / GPU / ...?

The only way to be "truely safe" would be to have the exact design of every chip in your machine, and some way to verify the physical chips have that exact design, but no Intel / AMD would never give you that, there is always some block you can't trust.


Firmware is typically lumped in with the hardware, and in most situations you are forced to trust the hardware (for lack of a better alternative). So you end up trusting the firmware.

Not that this is a good thing - trust never is in InfoSec! But if you're trusting the hardware, you don't gain too much by not trusting the firmware. If you want to scare yourself on this subject, watch Ralf Weinmann talk about the baseband software that every phone has but no-one ever thinks about: https://www.youtube.com/watch?v=fQqv0v14KKY

  • I wouldn't say that trust "never" is a good thing in InfoSec; there are plenty of occasions and contexts in which it is both needed and good. Commented Mar 11, 2016 at 18:13
  • +0. What's this "ophone" you mention? Commented Aug 22, 2016 at 21:45

Please keep in mind that the recent complexity of BIOS software (i.e., that it is vulnerable to attack), is a new development relative to the history of the field. Due to this, there are very few comprehensive threat assessments for BIOS and firmware software. To accomplish a secure situation, you need to use both secure firmware, whether open or closed source, and a secure OS. Using a secure closed source BIOS and a secure open source OS is a perfectly reasonable option.


As may have said, open source does not equal security. Open source is tremendously transparent, which can aid in review, but it assumes the review gets done. It also assumes the review gets done with your interests in mind. Is it being reviewed to a level you trust.

In many government labs, open source code is actually distrusted. They trust commercial closed source code more. There are many reasons, but one which is especially relevant here is that commercial closed source code has a commercial corporation behind it. If they have particular security concerns they wish to address, it can be easier to work with a company to resolve the concerns than it would be to hire your own expert to do the review. On the other hand, there is no company producing an open source product, so it can be very difficult to convince the legion of reviewers looking at the open source code to look at your particular issues. They have found that, in the case of adversaries intentionally writing backdoors that target them, rather than targeting any arbitrary user, are much easier to sneak into open source, and are not often caught in review. A company has much more to lose by permitting backdoors hurting their customers than a programmer writing open source in their free time does.


Even if you cant't trust the firmware, being able to trust the OS (and applications) increases the overall trust that you can have in the system.

Also, the firmware is seldom (if ever) used beyond booting the system and the chances of an vulnerability or backdoor therein successfully affecting the OS once it's up and running are next to nothing.

  • Cf. CISCO's Jetplow. How can you say the chances are next to nothing if the attack vector is built-in, demonstrated and totally trivial? How would it help if "the firmware is seldom (if ever) used beyond booting" (potentially from a network location), even if it were true? Commented Mar 14, 2016 at 7:53
  • I thought we were talking about desktop/laptop computers (and maybe mobile devices) here, where the firmware is used to boot the OS and then not again. Because in such systems the firmware is used only to boot the OS, and the OS then reinitialises a lot of things, it is difficult for the firmware to plant anything malicious in the OS. Commented Mar 14, 2016 at 13:23
  • Your "the firmware is used only to boot the OS" should read "the firmware is supposedly used only to boot the OS". Commented Mar 14, 2016 at 15:15
  • No, it is only used to boot the OS. The firmware can't do a thing once the OS has taken over the CPU and taken control of the hardware. Commented Mar 14, 2016 at 15:50
  • I am positive the firmware can install all kinds of backdoors and "hardware abstractions" (read: key logger) during boot. The firmware has access to the hard disk and the network. Hell, it could install a new kernel from wherever. It's not supposed to. That much is correct. For anything else all bets are off. You own the UEFI, you own the machine. You own the machine, you own the users. Commented Mar 14, 2016 at 16:15

I'd remind you that you should not let the perfect be the enemy of the good.

Yes, OpenBSD is at risk because it runs on closed source firmware. There is a bit of a catch-22 here. The closed source hardware platforms make up the bulk of what is commercially available on the open market. So if you want people to use your software/be of service to anyone else, you will need to run on some of that firmware.

From a security point of view, they can fix many problems with software security by writing and running OpenBSD software. The exploits that exist in firmware are usually done by a small and select group of people (most firmware attacks are much more specialized).

Given an open source operating system, open source hardware groups can start with a known software base. Without a large capital base, building both at same time is prohibitive (most years, OpenBSD barely has the base for the software that it writes).

Until a good and affordable open source hardware solution exists, complaining that people are not using an open source hardware solution seems like spitting in rain.

  • Moreover, open source software is (partly) secure because a lot of people are able to review the code and edit it,if necessary. Even if an affordable open source hardware solution existed, many people would not be able to review the hardware, especially at silicon level, because they lack skills and/or equipment. As such, affordable open source hardware wouldn't be a solution unless one also produces affordable tools for hardware security/validation AND a massive education campaign begins to teach people about hardware security.
    – A. Darwin
    Commented Mar 18, 2016 at 10:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .