OpenBSD foundation raised around ~380 thousand IIRC.
By creating OpenSSH and the fact all fortune 500 companies use it, I would say every year, the foundation should be bringing in around 1 or 2 million. It is time these companies really give back.
And while I am here, hardware vendors should open up their source, looking directly an Nvidia.
It's not the foundation that does the work but developers. With that kind of budget, the foundation is just administrative support. They aren't employing a lot of developers. Many developers are employed of course. Partially by those same fortune 500 companies that you mention.
Open source is a pragmatic arrangement where developers embedded in the industry can collaborate and share code; often explicitly supported by the companies they work for. It has worked very well for decades and there's no urgent reason to change anything.
For example, Damien Miller, who puts in a lot of time on OpenSSH, is employed by Google. Employing key contributors is how the industry supports OSS.
> For example, Damien Miller, who puts in a lot of time on OpenSSH, is employed by Google. Employing key contributors is how the industry supports OSS.
Yeah that's just confirmation bias. How often do we read about key open source libraries that are being maintained by one random dude in his free time, said dude's free time dries up, and suddenly everyone is in panic mode on how to get funding to him.
It'd be much nicer if every tech company above X amount of yearly revenue would be required to kick in 1.0% (0.1%? 2.5%?) of their profit into a foundation. That foundation then would put out bounties or contracts for open source project maintainers. The priority (= monetary value) of these would be decided on by a mix of community voting, open source expert panel, and commercial interest, split ⅓/⅓/⅓.
This seems reasonable, but my concern is that the money would not do much good. It could simply lead to a more powerful bureaucracy that prioritizes its own survival instead of it’s original mission, like what seems to have happened with the Mozilla or Wikipedia foundations. More money doesn’t always solve problems. It can simply create new problems.
There's a long tail of stuff that isn't paid indeed but I don't think this is confirmation bias. I maintain a few things myself actually. The thing is, I'm not actually expecting to get paid.I think you are underestimating just how many OSS developers have steady jobs and over estimating the urgency of the issue. I don't think the crisis you are outlining actually exists. But I'm sure there are individuals who'd like to get paid more for whatever they are doing.
If you want that, release your code under such a license.
Yes. What’s interesting is that this corporate software engineering socialism isn’t new with modern open source. It dates back to the earliest operating systems for IBM mainframes.
The openbsd foundation raised around 5 million, half of which has been spent. Curiously they aren't as transparent as they once were.
You mention nvidia support, others are hopeful for a better filesystem and wifi as well.
> .. wifi as well.
OpenBSD has supported 11ac for several years, and has the iwx(4) driver for modern Intel WiFi cards. There's also support for Broadcom FullMAC, bwfm(4), which is on e.g: Apple Silicon machines.
HaikuOS also has a port of OpenBSD's iwm/iwx drivers.
FreeBSD just recently announced they've started porting the OpenBSD iwx driver.. from Haiku.
https://freebsdfoundation.org/blog/laptop-support-and-usabil...
> The openbsd foundation raised around 5 million, half of which has been spent.
Citation needed, they've raised nowhere near that amount.
https://github.com/bob-beck/foundation-web/commit/483266cece...
Not OP, but they've raised $4,974,668 since 2014 (done by adding up all the thermometers at https://github.com/bob-beck/foundation-web), and I'm excluding anything prior.
That's certainly what they meant ;)
Your second paragraph is explaining perfectly why open source doesn't work and how its economics don't add up.
I would also add that it indirectly kills the vast majority of programming jobs - nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg. Nobody is ever get paid to write a new kernel as everyone can just use Linux. Very few people are going to get paid to work on a new database as you can just use Postgres...
Once there's a good enough open source solution in a field, in the long run it will out-compete commercial offerings, even it's overall a worse package, as it's some guy's free time project and is created on a $0 budget.
Programmers work for free, end users get a worse product, companies make trillions.
> open source doesn't work
What could you mean by that? It's an extremely successful model organizationally and technically.
> it indirectly kills the vast majority of programming jobs
All software kills the vast majority of jobs - think of all the jobs there would be if we had no software. Anyway, are we short of programming jobs?
Efficiencies create new, higher-value possibilities than, for example, JPEG decoders.
> It's an extremely successful model organizationally and technically.
There are technically impressive open source projects - e.g. Linux, and most of them have people paid to work on them full time. Those are the exception, not the rule. Most open source projects are some guy's hobby, done for free in their free time. Hobbyists solve problems they find interesting, and often ignore a lot of the "gruntwork" required to make a technically sound package. > Anyway, are we short of programming jobs?
Yes. Especially good ones. > Efficiencies create new, higher-value possibilities than, for example, JPEG decoders.
I don't see it - a large portion of programming jobs have devolved to gluing together a bunch of open-source libraries, doing the boring gruntwork to actually make them work, and dealing with the inevitable hell, caused by using 500 components that were never designed to work together.I don't think there would be jobs manually doing many things that software currently does.
> I would also add that it indirectly kills the vast majority of programming jobs - nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg
Looked at another way, open source means that instead of a bunch of programmers getting paid to write multiple implementations of the same thing over and over, so the programmers that otherwise would be doing that can instead work on new innovative things.
In an ideal world, all software would be open source, and programmers would spend all their time improving said software for everyone. The problem is I don't know how those programmers would be compensated for their work. In many ways, open source software is a public good, since anyone can benefit from it[1], so an argument could be made that OSS should be publicly funded (i.e. paid for by government grants). However, I am doubtful that the government could do a good job of allocating resources to open source projects. Then again, I don't think the private sector is doing a great job of that either. Just look at how many resources are put into showing people ads.
[1]: And it has the interesting property, that unlike most public goods, the cost does not scale with the number of people who use it, or have a limit on the number of people who use it.
Isn't the solution to have much shorter copyright terms? Software could be closed source at first, its implementation costs recouped, then opened by default when its copyright term lapses. New releases could still be closed, so income could continue. Set the term at 5-10 years, rather than >70.
But it is anti-alternative. It discourages alternative ways to do things.
This is bad in the long term because alternative ways of doing things open other avenues of investigation and development.
But all we get are improved versions of hammer when everything is made out as a nail.
> Your second paragraph is explaining perfectly why open source doesn't work
> some guy's free time project and is created on a $0 budget.
> Programmers work for free
You seem to be completely out of touch with what FOSS is.
The amount of relevant FOSS hacked by some teenager for free in moms basement is negligible. The largest contributors to the Linux kernel are IBM, Intel and Oracle. Nobody there works for free.
Because it costs down their own development costs, doing more with less.
How much upstream do you think BSD gets from Sony and Apple, besides a few crumbs?
clang was sponsored exactly to allow Google and Apple to take a compiler and not be legally obliged to upstream their sauce.
Nowadays clang has mostly replaced most proprietary compilers on surviving UNIXes, and embedded OSes, how much of those downstream changes land on upstream clang? It is mostly volunteer work improving ISO C and ISO C++ compliance, despite all the money being made by those folks.
> nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg.
if there's no technical reason why libjpeg isn't suitable, I'd consider it a huge waste of human life to create another. if there is a good technical reason to build a new one, then somebody will do it for free or somebody will pay for it to be made.
I think the system is working.
> Nobody is ever get paid to write a new kernel as everyone can just use Linux
Not that it negates your point in any way, but lots of people are paid lots of money to write Zircon (Google Fuschia's kernel) which is intended to replace Linux in many scenarios.
Sadly it went nowhere, it remains to be seen how long it will take to join Android Things, Tango, and other Google OS related projects.
Yes I am aware it is shipping on Nest Hub.
I will note that the number of people who actually work on the Zircon kernel directly is relatively small. Zircon is a small fraction of Fuchsia's codebase. However if you widen your view to include things that are not in the kernel but would be in Linux the math lines up better.
So they are paid to write a useless toy. While people who write the useful code are not paid.
Nobody is ever going to pay somebody to shovel holes when they can just use a back-hoe. So, let’s outlaw industrial machinery.
Open Source achieves the exact opposite of what you say. It allows people to direct their talent and effort to solving high-value problems instead of low-value ones. Instead of writing a JPEG decoder, you can create a professional photography workflow or a pre-press pipeline. Instead of writing the low-level bits of a database, you can create an enterprise SaaS.
Yes, Open Source infrastructure is hard to compete with. However, it is super easy to out-compete companies that are wasting their engineering resources re-inventing the wheel.
Of course, there is always the option of doing the basic stuff better of course and being rewarded for it. Some will.
And, while this reply is already too long to get into it, the majority of Open Source is written by people being paid to do it. So, wrong there too.
I wouldn't be a good way to spend money and resources to rewrite things like jpeg decoders again and again. It would not help to make the final product any better, but just siphon the money off from more worthwhile purposes.
Companies make billions? Good. It's time to tax them and use the money for the benefit of everyone.
And I ironically think that if you want to fix the open source you end up creating a good old economy.. where people don't give, but negotiate an exchange apriori so they know they won't be disappointed after the fact.
"nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg. Nobody is ever get paid to write a new kernel as everyone can just use Linux. Very few people are going to get paid to work on a new database as you can just use Postgres..."
There's still many paid offerings for databases, operating systems (esp RTOS's), and image processing. That includes libraries. The companies are usually profitable with some making a fortune on the products. Quite opposite of what you said.
The question you should ask is: why?
Next question: how do I use those lessons to sell and give away something like OpenBSD?
I think killing software jobs is a bit of a silly argument, it's not a better world that we've got 1,000 closed source jpeg decoders rather than one excellent open source one.
What I do find massively problematic is that the developers of the open source ones often aren't paid. That should be impossible, companies are profiting off of free labour and that's wrong. If anything open source developers should get paid more per accepted PR, they provide more value and probably better quality code.
Seems like the economics works better than 99% of our society does. The point of the economy is not to produce jobs, it's to circulate goods and services. Open source does this more efficiently in the long term. The American (or globalized) economy is mostly inefficient and irrational outside the perspective of shareholders and investors. Unfortunately, those same people will make us commit mass suicide before allowing the basis of resource management to change.
If we had to write every single piece of code over and over(or pay for them), computer science would have barely evolved and would not be so mainstream
Computer science evolved during the time when most people did not have a computer.
The concepts of compilers, operating systems, databases, file systems, computer graphics all evolved from the 60s to the early 90s.
After that, it was mostly scaling.
No, writing them over and over is literally what evolves computer science. Not having to write them over and over is what improves software. They’re different.
As a generic rule, it's true that open source software increases the supply of software, which means that the value of software goes down.
The reason this doesn't really matter in a truly noticeable way, and why I'm also not really concerned about AI taking programming jobs, is that demand for software is so much higher than supply. You can go to any random local small business, and within five minutes, you will identify software demand that is not being met adequately, or at all. They use Excel for their inventory and constantly have problems with it that need to be manually resolved. Their website doesn't work right and nobody knows how to fix the broken links. They have somebody who does paychecks by hand. One person is in charge of scheduling holidays in a shared calendar. And so on.
These companies would pay developers to fix their issues if they could afford them. As programmers become more productive, whether that is by using open-source software instead of writing things manually, by using LLMs, or by other means, there is a downward pressure on salaries. But that doesn't mean that jobs disappear; it just means that more companies now have access to developers they could previously not afford.
We make less money doing some in-house processes for a small, local business than writing a database for a multinational corporation. But on the upside, we improve the lives of people who actually matter, rather than making some billionaire even richer.
[dead]
> Programmers work for free, end users get a worse product, companies make trillions.
I bet you didn't use any Microsoft product. /s
You think microsoft doesn't use libre software?
When you give freely and generously to the community you should do so with no expectation of getting anything in return. Sometimes that expectation is fulfilled.
They are not talking about OpenBSD's expectations, it's about the ethics (!) of the companies using things on the back of the generosity without giving back.
I see this mindset more and more, and to me it seems against the ethos of open-source software. There's something philosophically odd about saying "you are free to use, change, redistribute, or sell this with basically no restrictions" while simultaneously maintaining that users incur unstated ethical debts by accepting. It could even be seen as a kind of bait-and-switch.
Contributions and reciprocity are praiseworthy of course, and we should all aspire to this. But that doesn't mean someone is ethically wrong for choosing to accept a gift freely given without giving one in return.
People choose BSD licenses precisely because they don't want to impose any ethics on anybody.
How many restaurants serve food and ask for donations from patrons instead of charge them specific amounts? People are not generous, large companies made of lots of people, none of which feel specifically responsible for the companies actions are also going to accordingly not be. If they need money, the expectations should be set accordingly. Maybe spruce should be open but features and bug reports must have accompanying bounties set by the individuals reporting them otherwise the maintainer will ignore them.
If you make it about ethics, it's not going to work. Your C-suite folks wont be on board.
You need to make it about utility. Open sourcing some package or contributions to an existing package is giving you returns far beyond your investment. A community will help maintaining, improving, growing your code. Perhaps even competitors will chip in. (If they don't, well, their loss..) It's going to be a net positive.
Use GPLv3 or AGPL then. If you want companies to "give back" when they use your code, put it in the licence.
Or you can charge money for your product.
Ethics does not belong to capitalism. Money is the central part of it, not ethics.
>it's about the ethics (!) of the companies
A company doesn't have ethics. It's sole purpose is to make a profit.
I would really like that the supermarket, my landlord, electricity and water company would equally be so generous.
Sounds like you're in favor of UBI.
The license says use it however you want with nothing in return. They usually get nothing in return. It's a license best used when you want maximum uptake by users, including proprietary products. It's also good for people who enjoy knowing others enjoy using what they build. Whereas, it's one of the worst licenses if a supplier wants money.
Lets assume goals like OpenBSD's. If one also wants money, they can make the software paid, free for many categories of users, source-available, and derivatives (mods) allowed. The paid part can be regular payments or one-time per release. Probably an exception to mods allowed saying they can't backport paid features from new versions to old versions but independent creation is allowed. From there, companies will pay to support it or they'll determine it has no market value.
There are proprietary, source-available RTOS's on the market for real-time and secure use. One source said, but I haven't verified, that INTEGRITY RTOS royalty-free was around $17,000 minimum per product or company. Another said LynxOS with communications middleware was around $50,000. A number of small vendors exist showing one can generate sales if their product is marketable. Tons of companies selling firewalls, load balancers, etc like OpenBSD is often used in.
https://en.wikipedia.org/wiki/Comparison_of_real-time_operat...
So, if money is important, they can change their terms to demand money some or all of the time. If the license says "free giveaway!," expect most people to treat it that way. I imagine quite a few of the developers have exactly that expectation. They are motivated by the joy of writing great code, not money.
> By creating OpenSSH and the fact all fortune 500 companies use it
It was a fork of Tatu Ylönen's SSH, so I think it would be more accurate to call it forking, not creating.
Of course, they've created a lot of new code as well since 1999.
From a fork of an old version that was still open source, the OpenBSD team audited every single line and rewrote most of it, AFAIR.
> It is time these companies really give back.
Our system rewards those who take as much as they can and give as little as they can. The tradeoff here is that each entity having a certain amount of freedom makes us happier since we can be different and choose to allocate our resources in different ways. But asking corporations to give back when they don't have to is like asking your neighbours to pay more tax because the roads need repairing.
You can't appeal to individuals, so the solution is simply to raise the bar on what that minimum is. The way to do that with software is to use copyleft licences. Support copyleft projects in any way you can and reject permissively licensed projects where possible. If we had stuck with copyleft we'd be so much better off.
> It is time these companies really give back.
I'm not going to sit here shilling for the corporates, but at the same time I think you need to put yourself in their shoes.
The stance you are taking is essentially the same as if a chugger stops me in the street and asks me to sign up to regular donations to $charity because "its only $1 a month". To which the inevitable answer is "sure, and there are a gazillion other charities, so I'm supposed to give $1 to all of them because its 'only' $1 a month" ? I will choose which charities and how much to donate to on my terms, thank you very much.
And its the same with corporates and open-source. Your favourite pet-project might be OpenBSD and you might think $evilCorp should give more to them ? But what about all the gazillion other pieces a typical $evilCorp will use ? OpenSSL ? curl ? ping ? traceroute ? In your idealistic world a corporate would give $1m to each of them I guess ?
The fact is the corporate lawyers know you've released your software on open terms. I'm sure they would be happy to buy an OpenBSD license ... but OpenBSD made their bed, as it says on their website "OpenBSD policy is simple — OpenBSD strives to provide code that can be freely used, copied, modified, and distributed by anyone and for any purpose. "
And before you say "well, they could donate instead of buying licenses" ... let's just say you would be naïve. Buying licenses is a "simple" standardised procurement exercise in most corporates. Meanwhile giving donations typically is a far more bespoke process involving far more administrative burden. And the smaller the recipient of the donation, the more admin burden required.
As others have pointed out $evilCorp does contribute indirectly to open-source. Many of the core maintainers and contributors to open-source are employed by $evilCorp and file their PRs to the open-source projects on their employer's dime, often whilst sitting in their employer's offices, using their employer's computers and infrastructure.
E-Corp typically has support contracts with vendors like Red Hat which in turn employ developers.
> I will choose which charities and how much to donate to on my terms, thank you very much.
Indeed. The observation is that generally for most corporations the charities are "nobody" and the amounts are "$0". If you, an individual, behave this way then you're a bad person. The argument is merely that the corporate "people" are also being bad people.
> In your idealistic world a corporate would give $1m to each of them I guess?
Why make this ridiculous strawman? If we said "some reasonable amount, distributed among their dependencies" why is that unreasonable? Do we have to draw out the whole picture before these people even attempt to consider what a reasonable contribution could be?
> The fact is the corporate lawyers know you've released your software on open terms.
Yes, and corporate parasites will therefore extract the maximum value while providing the minimum in return. History repeats itself.
> Buying licenses is a "simple" standardised procurement exercise in most corporates.
If you think about this for a few seconds you will realise it is not a good excuse. If ping/openssl/whatever had a "recommended contribution" listed on their "corporate licensing" page, then there is no administrative burden required whatsoever. You just pay whatever they ask, same as a license. You think the price is too high? Make up one.
So why is there a high administrative burden? Simply, because corporates themselves place a high value on "paying the bare legal minimum". In other words, they over-value the virtue of being cheap and unsociable. If your reaction to this is "that's just how business is", then good for you: according to your understanding, business is antisocial, and should be discouraged.
"hardware vendors should open up their source"
this doesn't make sense, how can you expect hardware companies to do this, where the moat???
It's not as bad as it used to be, but one moat some companies had was "excellent support for Linux/Unix/BSD". Until CUDA no one in their right mind would buy Nvidia for their Linux workstation, just like you'd avoid certain Broadcom wireless chips.
Hardware companies need their devices supported by as many operating systems as possible, especially if those devices can be used in servers, desktops less so. Apple is pretty much the exception.
having support for linux != open source their shit
You can still support linux while still having closed source
Source code is often still very confusing without accompanying documentation. A weird cryptic series of register writes with random values makes it difficult to really understand what's going on.
Capitalism is based on the exploitation of workers who are directly hired by a company, now imagine if a company would pay someone who it doesn't have to
I'd change "workers" to "persons with little capital".
Any example of exploitation in the capitalist tech industry, and what job under any other system is not exploitative by comparison?
[flagged]
The beauty of FOSS is that it does not ask for anything in return (the 4 freedoms). That's exactly why things get adopted in the first place. Because you are free to use them as you see fit, which is why Fortune 500 companies use them in the first place.
> It is time these companies really give back.
There's no reason for them to do so while maintainers continue to be willing to work for free and governments take a lax stand on security breaches.
[flagged]
They could easily raise a few million if they bothered working on sales, but they don't.
Its not really a for profit project and I prefer it stays that way. Projects that raise money tend to get "corrupted" by the greed.
Not that there is anything wrong with raising money, but the ideology behind openBSD don't really fit if they go for profit
a) they shouldn't have to
b) part of what makes it great is that they don't
They have a sales team of online enthusiasts who work for free. Unfortunately, they got what they paid for.
> Unfortunately, they got what they paid for.
Industry wide adoption?
John Ioannidis (first name on the list… IPsec) passed away a few weeks ago and almost nobody noticed.
I attended a memorial on Zoom and people said he also created the building blocks that permitted Mobile IP (IP on your cell phone) to work.
Thank you for letting us know. Have you tried to submit something for the front page?
If you knew John, then my condolences. We're all using the things he built, every day.
Oh wow, I was not aware of his passing! Thank you for sharing that information. RIP John :(
In addition to work pioneering privdrop/privsep design for network daemons, and the almost ubiquitous adoption of pledge(2)/unveil(2) across the base system, I think people are missing out on much more recent mitigation work, such as mimmutable (which Linux is just beginning to land with mseal), on OpenBSD, most of a programs static address space (.text/ld.so's .text/.bss/main stack) is now automatically immutable.
There's also execute-only memory and BTI/IBT on modern Intel/AMD, and ARM machines, enabled by default. Including a significant amount of ports development work to make the larger software ecosystem ready for this.
Execute-only memory on ARM is a footgun (bypasses PAN); Linux and macOS both block it. OpenBSD probably should too.
Why? OpenBSD seems to think execute-only in userland is important. We've had SMAP on x86 for many years, it helped fixed bugs early, these bugs are rare now, so why is everyone concerned about kernel accesses that aren't using copyin(9)?
EPAN is already supported, hardware is now arriving, it's used if available, but the idea that execute-only was less important than PAN was probably misguided.
If you have EAN feel free to turn it back on but I generally believe that execute-only is less important than PAN, yes.
How does execute only memory disable privileged access never memory? The bigger problem I expect is the overhead of loosing PC-relative loads unless the hardware still allows these as instruction fetching related? Would you have to dedicated one of your 31 GPRs as the table of contents pointer similar to PowerPC’s ABI (e.g. sizeof(void()(void)) == 2sizeof(void *))?
https://blog.siguza.net/PAN/ has a nice summary of the PAN issue. Also, you can't load data under execute-only but you can execute it (e.g. by jumping there). If you are compiling under this scheme you need to tell your compiler that this is the case.
A phenomenal resource on the same subject:
I like this -- despite the clown nose logo, it's actually fair to my eye and is respectful to parts of OpenBSD that are thoughtfully designed.
OpenBSD is thoughtfully designed because it is one of the best examples of "design by dictator" (Theo) - and a small core team - as opposed to design by committee like every other OS out there. Look me in the eye and tell me 90% of changes and unnecessary features in macOS aren't there because some team needs to justify their existence.
What features in macOS are you referring to?
I assume you meant to write "disrespectful"?
While much of this document is openly disdainful, there are areas like the malloc implementation[1] and features like the atexit hardening[2] where OpenBSD is unambiguously excellent, and it says as much, noting that the latter is a "pretty cool mitigation".
I used to do some OpenBSD ports work, and even got a tiny patch into the base system. I love OpenBSD! I don't have an axe to grind here! But it is not above reproach, and I think this site is overall harsh but fair.
Besides the clown nose on puffy it's honestly just realistic and not all just talking bad like I've seen some people do:
They are very positive about some mitigations:
Sure. I like pledge --- though I think OpenBSD should just do eBPF too.
Maybe it's just limited resources? In a project that size, I can't imagine having to keep up with the resources of Linux (and to a degree with Apple, Google, and Microsoft) on one side and with all the attackers on the other side. And they want - their reason for being is - higher quality code and security than the rest.
Their 'unusual' approach to security might be a distraction they don't need. But maybe it's the only way to hope to pull it off? Maybe they can't do it the GLAM (Google, Linux, Apple, Microsoft) way with OBSD's resources.
This looks quite concerning: https://isopenbsdsecu.re/mitigations/packages/
Outdated FUD, OpenBSD's Mozilla port maintainer regularly updates and backports non-ESR Firefox to the -stable tree.
https://freshbsd.org/openbsd/ports?q=firefox
Tor browser bundle is also being updated consistently.
[flagged]
But openbsd does have a code of conduct. you can find it here.
The author neither complains about it, nor says they are bothered by it. “This website was done because studying mitigations is fun, not to get involved in a huge flamewars or endless bike-shedding on mailing lists”. Misrepresentation is a poor showing. Perhaps we should take everything you write with a grain of salt, hmm?
Fun fact, Hacker News also has guidelines for conduct.
Yeah I was worried for a second jcs might have something interesting to say about backward- and forward- edge CFI, but then I remembered he's woke and closed the tab before the mind virus could get me.
> Random-data memory: the ability to specify that a variable should be initialized at load time with random byte values (placed into a new ELF .openbsd.randomdata section) was implemented in OpenBSD 5.3 by Matthew Dempsky.
What's the use case for this?
EDIT: further down is one example:
> RETGUARD is a replacement for the stack-protector which uses a per-function random cookie (located in the read-only ELF .openbsd.randomdata section) to consistency-check the return address on the stack. Implemented for amd64 and arm64 by Todd Mortimer in OpenBSD 6.4, for mips64 in OpenBSD 6.7, and powerpc/powerpc64 in OpenBSD 6.9. amd64 system call stubs also protected in OpenBSD 7.3.
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib...
Many things, retguard uses this for per-function random cookies, for instance.
The bootloader uses this mechanism to pass data to the kernel.
https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00...
I suppose: Sometimes things work fine with the implicit default value that you end up with. So this will cause problems when you forget to initialize values to expected sane defaults.
I would imagine that the use of uninitialized locals could no longer be deterministically used to exploit a program.
Really surprised that pledge / unveil isn't featured more prominently on this page.
Everything I've read about pledge and unveil really admire the approach and the results but it didn't seem to have a big impact outside of OpenBSD. It took ~20 years for OpenBSD's CSPRNG to be re-implemented everywhere else maybe we're operating on a similar timeline here.
While not the same, this is a SECCOMP-based Linux alternative (and it can even be used to restrict pre-compiled binaries).
We definitely took inspiration and implemented in the nanos unikernel cause we think it's a great idea:
https://nanovms.com/dev/tutorials/applying-sandbox-security-...
This is generally how modern systems do sandboxing.
Well, it's in date order. But they could do with a line or so of explanation
Maybe I'm not getting something here, but I find the pledge/unveil approach confusing.
Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions? What is allowed should be set externally from the program, similarly how I can map filesystem volumes and add capabilities to a Docker container [1].
I'm not familiar with BSD and I only used it a couple times out of curiosity. What am I missing?
[1] https://docs.docker.com/engine/security/#linux-kernel-capabi...
The threat vector is not that you don't trust the program, pledge/unveil is completely unsuitable for that. but that you worry the program will be compromised while it is running.
so the observation is that programs tend to have a startup state where they need access to files and a run state where they don't. so pledge/unveil is a mechanism for a program to inform the os that it no longer needs access to files/syscalls and any future access should be considered a hostile takeover. please kill me.
> Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions?
Because the admin or owner will know FAR less about what a complex program needs at all times, and when it will be safe to drop privs. A database might be tested for a week and then it has a special snapshot thing done for the monthly backup and you did not foresee this, whereas the coders would know what perms are needed in order to do these dumps. Hence, you can't set perms just once before starting, and as a user of said software, you can't expect to just make a quick test and then design a fully working harness for it either.
Also a great resource:
Have they implemented ISO C11 _Thread_local yet? It's been the number one annoyance¹ with porting software to OpenBSD. It is (was?) the only mainline OS without support for native thread-local storage.
¹ e.g. https://github.com/FRRouting/frr/blob/3f290c97e8325bd9db9363...
I believe their system clang support it with -femulated-tls.
Pretty sure we tried that and it didn't work, but that was at least 2 years ago... time to retry I guess.
Emulated TLS isn't particularly great though in any case :/
For those interested in actually supporting some of this work:
Incredible. I wonder what's the debugging experience for userland developers with all these security features enabled (especially the memory randomization ones).
My general experience has been that it’s great at turning rare crashes into frequent crashes, which are much easier to fix.
Can't you launch the debugger as root and attach to the process? Which is to say, I'd expect the experience to be approximately the same.
Alternatively, debug in a VM where the security features are disabled.
> especially the memory randomization ones
I have never once relied on memory addresses being reproducible between program runs. In an era of ASLR that seems like a really bad plan. Plus multithreading breaks that for malloc'd stuff anyway.
Is OpenBSD suitable for daily use on a laptop?
Does anyone have such experience? Is it ok?
The developers often use ThinkPads, and so consequently it works quite well on ThinkPads.
Your experience will be a lot more variable on any other laptop.
Worth remembering that OpenBSD has no support for bluetooth, which many users often require on a laptop.
Small usb bluetooth dongles work, they show up as a regular audio device. I use one and sndiod can set set to automatically switch back and forth to it.
I run openbsd on my laptop, a thinkpad x260 with an ssd, and it works great.
Worth mentioning lack of Bluetooth is only because they felt the existing BT stack was not up their standards and ripped it out rather than let it rot like most software.
It depends on what you need for your daily use, OpenBSD has ports of common desktop environments, KDE Plasma, GNOME. In fact, thanks to KDE and GNOME port maintainers, Rafael Sadowski, and Antoine Jacoutot, respectively, OpenBSD 7.6 -current has the latest versions of both (KDE Plasma Desktop 6.3.1, GNOME 47).
I recently checked out KDE 6 for the first time last year, it really is as easy running as 'pkg_add kde kde-plasma kde-plasma-extras' and then reading through the local pkg-readme file, that said if you're not familiar with OpenBSD it won't be like other systems where it comes preinstalled and preconfigured.
https://brynet.ca/article-l13gen2.html
There's many popular window mangers and applications you can install using the package tools, as you'd expect, including Chromium and Firefox, but you can quickly search here: https://openbsd.app/
I use OpenBSD. You must check the hardware support. If it works, it works far better than Linux from my experience. Somethings to take note:
1. Power management may not be as good as with Linux
2. No HDMI sound support
3. No bluetooth
4. You need to be comfortable with config files and man pages.
5. Probably fewer applications in the ports tree (I have all I need).
If you are fine with the above, OpenBSD is the finest OS I've used so far. I've never run into random issues like wifi connectivity, audio issues like with Linux.It was a few years ago, but I ran OpenBSD for about a year in college (on a Thinkpad). It worked because I rarely needed anything more than Firefox, code editors, and a shell with ssh. Most of my time was spent reading, writing papers, writing emails, and writing code.
my big issue when I looked into it was the default filesystem was quite an antiquated design that would lose or corrupt data in a powercut or unexpected shutdown. Last I checked many of the devs have fairly elaborate uninterruptable power supplies to deal with this.
A lot to like about openBSD; doas is my daily driver on linux, openbsd man changes are incredible, but I'm not going to mess about recovering disks just because I forgot to plug my laptop in.
I use it, and even run wayland (sway) on my dell laptop. No bluetooth support. Encrypted disk. Takes a lot of time to setup. Generally similar to linux, but less hardware support.
It works quite well. The OOB experience is very complete and hardware gets picked up without issue. However you’re limited in the amount of apps and it’s also incredibly slow, so you’ll need to really use minimal, fast cli apps.
I left it ultimately because it had way worse battery life than Linux on my T480s and I also wanted to play some games with steam.
> it’s also incredibly slow
I never used OpenBSD. Why is it incredibly slow?
You could probably get close to the same experience by running your BSD in a VM when you need it?
Yes but depends on the laptop.
Get a Mac laptop. OS X is based on BSD.
OpenBSD is as different from macOS as Windows 11 is from OpenVMS.
Common misconception. It is not. The kernel is XNU, and the OS base is Darwin which has some BSD parts in it, and some of the userland came directly from FreeBSD (though heavily modified).
carp is one of my favorite things to come out of OpenBSD. It's awesome combined with HAProxy. I really enjoyed managing that system.
I also like OpenBSD's release art/songs.
"Hello, I'd like to by a CARP license please."[0]
Thanks for posting this, I think in our industry provenance is an underrated piece of knowledge.
Position-Independent Executables (and ASLR) were used by AmigaOS back in 1985. It had to, since the Amiga lacked an MMU, and had very little memory, so anything that was loaded had to be placed at whatever ram was available.
It didn't need the executable to end up in a single block either, every individual section could end up in a different location. Compilers produced large numbers of sections to facilitate this process.
That's not what's meant by PIE though. It means the code can appear at any address and still be valid.
Amigas could, of course, have position-independent code. Use BSR and BRA rather than JSR and JMP; use LEA label(pc),A0 / MOVE.L (A0),D0 instead of MOVE.L label,D0 .. but the limits for PC-relative addressing are +/- 32k so you need to get creative to reach code or data further than that.
More commonly, Amiga executables had relocs, a list of fixups to apply. The code on disk in each hunk was written as if all hunks were loaded at address 0. There was then a list of relocations at the end of each hunk, saying what offsets in that hunk need the base address of another hunk (including themselves) added there, to fixup the absolute address reference.
This is relocatable code, but not position independent code. If I used an MMU to make that relocated code appear at another address, all its absolute addressing would be wrong at that new address.
Position-independent code can be shared by multiple proceeses, and appear anywhere in their address space, while only existing once in memory
Well, PIC, as it commonly is done nowadays (via PC-relative addressing), requires the static/global data it references to be postioned at very specific offset from it. Which prohibits one not only from e.g. putting in 16 GiB away (why would you actually want this?) but also from having unduly large code modules — x64 only provides ±2GiB for PC-relative addressing so you'd have to use some sort of indirection scheme anyhow.
Well, resident programs (actual Pure residents in AmigaOS) would be like PIE, though that came a bit later, and gave the same effect, several programs could run the same code with different set of registers, and all data was pointed to by registers and no globals.
Big respect to OpenBSD. Now all it needs is a FS with ZFS's core capabilities and it'll be almost perfect.
A LOT of those innovations were first present in grsecurity/PaX. Back when it was freely available to everyone as well. I guess the arguments is the OpenBSD has them by default with needing a 3rd party patch, that's why they're claiming them as their innovations?
Yup! The idea behind Pledge/Unveil was first in Landlock also.
> that's why they're claiming them as their innovations?
I think they are just listing their specific implementations as innovations, their particular approach. Too many of what they list was definitely not an original idea, so they can't possible be suggesting otherwise. At least, I would hope not.
> The idea behind Pledge/Unveil was first in Landlock also.
This is so plainly, and verifiably untrue, that it's almost funny. The patch series and kernel commit adding Landlock to the Linux kernel even references OpenBSD pledge(2)/unveil(2) as a source of inspiration.
https://github.com/torvalds/linux/commit/17ae69aba89dbfa2139...
https://lore.kernel.org/linux-security-module/20210422154123...
> Yup! The idea behind Pledge/Unveil was first in Landlock also.
Landlock was released in Linux 5.13, in 2021. Pledge was released in OpenBSD 5.9, in 2016. As far as I'm aware, Pledge is the first of its kind.
I am guaranteed to get grief on this but an anti-Innovation in OpenBSD (so obsessed it is about security) is to use an unsafe language like C everywhere in kernel and user space.
The implementation of OpenBSD predates many safer systems languages but I think OpenBSD should now start moving to a checked variant of C or a safer language like Rust/OCaml/Odin/Zig/Something else.
The conversion can start with some OpenBSD user space programs. I notice a steady stream of C related security fixes in the OpenBSD changelog. Many of these could have been probably avoided if the implementation language was more “safe” by default.
I doubt that this is going to happen but I think it is fair to point out that using C does give you some additional security headaches by default.
Theo has addressed this directly. I cannot find the video at the moment - it is somewhere on YouTube - but his response essentially is okay, so where is 'cat'? Where is 'grep'? Where is Korn Shell?
Everyone is busy jumping up and down and bitching about reinventing the wheel in Rust but no one has even taken the time to rewrite the simplest of Unix tools in Rust.
Not to mention OpenBSD has a rule that "base builds base" and the Rust compiler is a bloated monster that would fail that most basic task.
So where is the benefit?
>no one has even taken the time to rewrite the simplest of Unix tools in Rust.
"The uutils project reimplements ubiquitous command line utilities in Rust. Our goal is to modernize the utils, while retaining full compatibility with the existing utilities."
The worst part is when you come across something advertised as a replacement and it does something like 80% to 90% of what the original does with a WONTFIX for the rest. That can certainly be a valid choice in some cases, but for core tooling it's not realistic to expect widespread replacement to happen in that scenario.
lol? These have been rewritten several times by various people, it's almost a meme at this point to make "x utility but in Rust".
so where is 'cat'?
https://github.com/sharkdp/bat (Haven't used this one, but it's pretty popular)
Where is 'grep'?
https://github.com/BurntSushi/ripgrep Use this one often. It's fast af to search a directory of source code.
Where is Korn Shell?
https://fishshell.com/blog/fish-4b/ Fish is now entirely in Rust, very popular, and to be frank basically a step above bash or ksh.
https://github.com/uutils/coreutils
Parent wasn't about rust specifically. Just something safer than C
It will not be Rust, since this has not happened after so many years of Rust existing. It will be some other language.
While I totally agree, OpenBSD has a goal to run on some legacy & esoteric hardware.
Hardware that isn’t supported by many of these “newer & safer” languages.
Well Rust has the most momentum, but going from C to Rust is quite a jump.
Zig isn't even 1.0. Odin,DasBetterC have not much uptake.
OCaml has a GC which is a non-starter for kernel, it could be used in user space sure.
The folks at Xerox PARC, ETHZ, DecOlivetti, Microsoft Research, MirageOS, disagree on what a GC is good for, even if the market mostly thinks otherwise.
Of alternatives, I think Zig is closest to what they like. It's small, easy to maintain, has great tooling for C, and already used for high-reliability (TigerBeetle). I don't know if its portability is as good as they like, though.
I wonder if we could get router based on OpenBSD.
It does the job great with the default install as long as you're comfortable with the console but if you're talking something with a web interface like what pfsense/opnsense on freebsd, there was one out of Sweden I think it was for a while that fizzled out called securityrouter. Nowadays these are what I've seen (But not tested):
yes we can - https://www.openbsd.org/faq/pf/example1.html
I use OpenBSD as my router and have for years. Works great.
W^X is only true in an extremely narrow sense. They said they were first, and that it cannot be done on x86. Which was a surprise to me, having run it on multiple Linux architectures, including x86, for years with PaX or grsec.
Then I guessed they looked around, and saw oh we can do it on x86 too, the pax way.
Does OpenBSD still have a giant lock?
Genuinely curious, and it’s been years since I’ve looked at it.
It has, and it is used less and less. Not sure if any OS never does it anywhere, but the important part is to remove it from all "hot paths", not to remove it where its not relevant.
Can't say if they still do, but FreeBSD for the longest time used to list the floppy driver being one of the modules using GiantLock and that was a problem for what I guess was about zero people.
But if one asks fbsd devs if they still have it, they would have to answer yes, even if the rest of the OS runs super great without locks anywhere else, so the binary question of "is there somewhere something that for some time could possibly call the giant lock" isn't very interesting, but rather "will it do it for the tasks I imagine I will run on my machine?" and that would have to be a more fine-grained question with some research, just like the locks in the kernels are getting more and more fine-grained.
Most of that is gone and the performance upswing is very noticable. A little bit of work remains.
> It turns out that all the OpenBSD locks boiled down to a global netlock rw lock for the entire IPv4/IPv6 stack.
I guess addressing the network stack is work that still remains?
I still see spl references so I think so?
I am hopeful for got (game of trees).
OpenBSD still uses CVS, and I suspect its development will benefit greatly (actually accelerate) from the switch, once it eventually happens.
For someone who’s interested in getting into any *BSD, which should I go with? OpenBSD or FreeBSD?
I use OpenBSD. I love it, but I recommend reading warnings on the label.
I would say FreeBSD is somewhat like Ubuntu is to Linux - easy to get setup, works for more people.
There isn’t anything like OpenBSD in the Linux world - where the primary focus is system correctness, even at the cost of user convenience at times.
What's your use case?
(FWIW, there several other *BSD's.)
I don't have any specific use case yet, I'm planning on having a little server at home. Things I'll use it for is hosting small apps, local dns server, monitor our LAN and maybe act as a host for multiplayer games.
> This is a list of software and ideas developed or maintained by the OpenBSD project
(Emphasis mine.)
Yet they can't manage a unified page cache like every other OS on the planet? I'll be more receptive to the concept of OpenBSD innovating when their virtual memory subsystem gets over Reagan leaving office.
* Best man pages ever
They forget to list The0's comebacks
It also leads the BSDs in RISC-V support.
Off topic: I'm wondering why OpenBSD pages (and many "*ux") just uses basic HTML with no styling or CSS?
Typography matters for readability. For the minimum get a decent line height and limit the line length to 60-ish characters.
Are OpenBSD not taking (potential) users seriously? User experience matters, and the readability of the docs is part of the UX.
(sorry for the rant)
That page uses CSS though. Maybe we're looking at different view-sources.
And for readability I already have my browser set up with my favorite fonts and font sizes and background/foreground colors. How can I expect every website to guess my preferences perfectly, as opposed to all the other people with different preferences. So I just set it up one time in the browser UI and it just works everywhere.
If a user is not able to navigate a font/color selection UI but wants to give technical advice to the OpenBSD team, I think it's that user not taking OpenBSD developers seriously.
wow, 25+ years later and ipv6 is still not fully integrated
OpenBSD was the first system with an IPv6 stack.
What? I think you misread. The IPv6 stack was "almost fully operational [already] by june 1996".
Perhaps one day the OpenBSD folks will figure out how to completely prevent user programs from making syscalls. It seems they are mostly there but still not quite. Please don't mention WASM in your replies.
Are you referring to their only allowing syscalls from libc? Because AFAIK that's fully functional already?
Or if you're trying to solve a problem, what are you doing that pledge() doesn't cover? For that matter WASM.... would do that, so why not use it?
It's rather hard to do anything useful if you disable i/o.
Precisely! And yet they make it really hard for my shellcode to do anything useful for some reason, ugh.