For anybody wondering about the new pinsyscalls(2) suggest having a look at
https://isopenbsdsecu.re/mitigations/pinsyscall/ . To be clear: I use OpenBSD on all my external-facing systems. I trust it infinitely more than any GNU/Linux distribution (esp with the recent xz.. "issue"), but I think it's important to do your own research and see what the contrarians say from time to time.
Would it be correct to say that OpenBSD is far more of a unified approach to kernel and userland development than GNU/Linux? As in, both ship as one unit, end-to-end, instead of interchangeable modules that make up GNU's ecosystem?
In very approximate order, and I suspect that there are (wild approximation) half as many users for each step down the list.
One estimate I've seen is that there are ~7K users of openBSD, in total, worldwide.
There are a few distros of FreeBSD. None of the others have distros, AFAIK. PC-BSD was a FreeBSD distro. iXsystems acquired it, turned it into TrueOS, and then killed it 4Y ago.
Having had some experience with FreeBSD, I'd pick BSD over Linux any day, the primary reason being its unique consistency, which is after a few days a breeze of fresh air even to a newbie. The vast majority of software that runs on Linux is available for BSD as well. Sadly, hardware support is not that great.
This site is often fairly balanced, but I think the author often jumps to conclusions. The pinsyscall feature is one place where many security researchers have jumped to conclusions, because they only see it from their narrow x86 oriented view.
Yeah, on x86, I can craft a ROP attack that allows me to discover relocations for functions fairly trivially, especially for coarse ASLR, because I can read the text segment. But, ARM64 has execute-only support so that it's possible for code to execute, but not read, a text segment. In this situation, pinsyscall does add a valid defense in depth layer. It's still imperfect, but this does in fact raise the bar necessary to carry out a ROP attack when combined with randomized re-linking on boot ASLR. Further, once dynamic linking has occurred, the text segment for a binary is made immutable so that no mapping changes can occur, including mmap.
I think that OpenBSD still has a long way to go before all of these defenses align, but they are far less trivial than the author makes them out to be, because none of them are meant to be used alone. OpenBSD developer decisions like these can sometimes appear to be casting about randomly, because they are making small improvements instead of building toward a particular goal. Sometimes, they hit gold as with W^X, which was widely adopted. Sometimes, their ideas stink, like systrace. But, I don't think it's wise to just dismiss these ideas out of hand.
Instead, I recommend that people look to the history of OpenBSD, which has been more of an evolutionary approach to security instead of a revolutionary approach (i.e. Fuchsia). From an evolutionary perspective, pinsyscall makes sense as it is low-hanging fruit that can buy some security and can force applications to use a standard interface (libc) instead of making raw system calls. From a revolutionary perspective, pinsyscall just seems like a dead end. Revolutionary design has convergent effects -- all of the pieces come together in a perfectly engineered defensive shell. Evolutionary design has emergent effects -- fixes and features build on each other until they co-evolve into strong defenses.
> ARM64 has execute-only support so that it's possible for code to execute, but not read, a text segment.
OpenBSD does xonly by default on multiple architectures (arm64, risc-v, ... g5 powerpc), including even amd64 on recent Intel/AMD CPUs supporting MPK/PKU:
On machines that lack hardware-enforcement, at least on CPUs that can differentiate between traps for instruction-fetch and data-fetch, there is still benefit:
I've been following CHERI for years. I'm a fan of runtime mitigations in hardware, better process isolation, and capability models. This couples nicely with an obsession of mine, which is the integration of formal methods into system and firmware development.
That being said, CHERI has a long way to go before it makes it to any production system. ARM Morello has certainly breathed new life into it, as has its current push toward a RISC-V ISA. Going from R&D to synthesis on production hardware is a significant leap.
It has inspired innovation in hardware much as seL4 and similar projects have inspired innovation in the formal methods field. For that, I'm grateful.
While it might have inspired innovation, there is SPARC ADI that predates it, with Apple's PAC, Microsoft's Pluton, and ARM's MTE already being deployed on some systems.
Still looking forward to CHERI ideas to go mainstream though.
Only Intel and AMD keep messing up their attempts to hardware memory tagging, for several decades now, starting with iAPX 432.
At this point, I think that Intel and AMD have designed processors that are hostile toward security and process isolation. The amount of work required by an OS designer to work around the default insecure and leaky behavior of these processors is staggering. Worse, there is always the temptation to optimize performance by turning off these mitigations.
Perhaps that's why I enjoy working on microcontrollers and firmware. Yeah, there are potential CPU attacks on these, but it's much easier to manage mitigations, and these mitigations don't come with steep performance penalty trade-offs.
Would the evolutionary approach be an advantage in allowing existing code bases to run with minimal modifications? So not perfect but safer than linux with minimal effort?
I think that it's difficult to quantify whether X is safer than Y. Instead, we should look at what safety measures X or Y have in place, and whether these can be reasonably improved. Certainly, a single comment on a forum would do this topic a disservice.
OpenBSD has clearly been in the business of making small improvements with each release. This model has worked for them, but it has also been part of what makes them controversial. I trust OpenBSD for my personal servers and my travel laptop. I use it as a build target for my projects.
That being said, do I think that people should switch from Linux to OpenBSD? I wouldn't do this purely for security, because Linux has not been sitting still either. But, I think it's definitely a good idea to take lessons that OpenBSD has taught when configuring a Linux server: disable things you don't need, use the most aggressively secure options for services you provide, and add as much isolation between pieces that you can. Regardless of which OS you choose, you should spend time familiarizing yourself with what is required to harden the security for servers you make available with a public IP address.
OpenBSD's "secure by default" idea is great until you need to enable a service, which widens its attack surface. Doing this safely requires research and knowledge. In this way, I don't think that OpenBSD is much different than the average Linux distribution. I openly admit that I like OpenBSD, but I don't want to steer people the wrong way by claiming that they would be safer using it. In fact, blindly switching operating systems could make folks less safe, because they will probably use the new operating system incorrectly. Instead, study and experiment.
Do you think there's more value in combining 2 heterogenous systems (like openbsd up front, linux behind) than using one 'more secure' system throughout? I feel like the number of critical issues that have faced two systems at once is far fewer than a single system.
Also I think it shows value in having independent implementations of standards. If you have 5x different xz tools or C compilers or Javascript engines, the threat is chopped in half, plus you can easily compare reference outputs between them (RE: on trusting trust)
For sure! An argument in OpenBSD circles is that contrary to popular belief one can have security through depth. This means that even though you'll never be 100% secure you can definitely make an attacker's job harder and their life more miserable. Of course, if the NSA wants to attack you then they'll probably succeed, but for your average script kiddy / botnet scanner / worm exploiting some vulnerability having multiple layers might be enough of a deterrent.
I'm not a security person but I also think a lot of malware damage comes from companies / users using misconfigured or outdated software. As such, if you were a sysadmin, knew what you were doing and had the time, then running GNU/Linux is probably fine, but I'm not super knowledgeable. I just want to host a website or run a tor-relay on a VPS and not have to worry about updating my system as soon as some 0-day is announced in glibc or systemd; even if it's in the service itself, my hope is that by using a non-mainstream OS the exploit might not initially target it, hence giving sufficient time to see the news somewhere and patch / update.
Didn't Go already realize that it can't use direct syscalls on anything other than Linux? They made some mistakes in the past but by this point I think they learned their lesson.
On Linux, using direct syscalls is a good idea, since it's the stable userspace-kernel interface. There's really no need for libc on Linux, each language should just implement it's standard library on top of syscalls.
They knew it all along, since it's well-documented. But they don't seem to care about it until they get burned. Which first happened on macOS, so that was switched; then OpenBSD.
Ironically the libc itself fails to document how large of a stack you should have before you call into it. Which is why go, having goroutines, tried to avoid it in the first place.
They didn't "get burned" they were "trying to provide a nice feature that wasn't as broadly compatible as they had hoped."
When Go first shipped, it was already well-documented that the only stable ABI on some platforms was via dynamic libraries (such as libc) provided by said platforms. Go knowingly and deliberately ignored this on the assumption that they can get away with it. And then this happened:
If that's not "getting burned", I don't know what is. "Trying to provide a nice feature" is an excuse, and it can be argued that it is a valid and justifiable one, but nevertheless they knew that they were using an unstable ABI that could be pulled out from under them at any moment, and decided that it's worth the risk. I don't see what that has to do with "not being as broadly compatible as they had hoped", since it was all known well in advance.
Like many other decisions, and as it happens with other technologies, reaching for it is a decision that outweights my preferences, given how it has managed to become unavoidable in many CNCF and DevOps products.
> There's really no need for libc on Linux, each language should just implement it's standard library on top of syscalls.
Its not always not so clearcut. For example using pthreads instead of just calling clone can be useful for interop etc. Similarly, anything involving NSS is probably best done through libc. Having libc malloc integrated makes interacting with other C libs easier. And so on.
Yes, I run -current so I update packages frequently.
After tedu's comment here I installed 7.5 in a VM and could build and run my Go software in it successfully, so I figured there were some Go build or config files or something somewhere getting in the way. I pkg_delete'd go, removed every Go build/config file I could find, and re-added Go with pkg_add. Now I can build apps with the previously mentioned modules; everything works fine now.
Can anyone comment on the OpenBSD security model in 2024? Is it more secure than a minimal linux distro (or one configured to be so) such as Ubuntu Minimal or Debian Stable?
I'm finding it quite difficult to compare OS "security" these days, whatever that means. Everyone seems to have their own crackpot opinions. If anyone with a security background could chime in, I'd be forever grateful.
> OpenBSD has no Mandatory Access Control (MAC) system like AppArmor or SELinux which prevents you from fully locking down user space.
Isn't that pledge?
And in general, I observe that lots of people are happy to say that OpenBSD's protections are no good, but somehow they can't be bothered to actually show a working exploit.
I'm not really super confident, but I think the problem is that sshd has to be able to spawn user sessions and those users are generally not supposed to be (meaningfully) confined by selinux or whatever. So I suspect that it wouldn't have helped, because a compromised sshd is necessarily in the prefect place to MitM or forge a session regardless of extra constraints. But take with a grain of salt.
What does this mean? 64-bit inode numbers? 64-bit timestamps? Something else?
> Also they removed softupdates,
Shame in a way, I remember reading McKusick's paper and being impressed. But I guess it's the antithesis of batching, which turned out to be more important for performance than avoiding the extra I/O due to journalling. Also the implementation was AFAIU fearsomely subtle and tricky.
With unveil(2) and maybe pledge(2), I do not think there is a need for Extended Attributes. To me, all it does is add complexities not really needed in OpenBSD.
You confuse ACLs and xattrs. SAMBA uses Extended Attributes to store thinks like Hidden and System flags on files, so that Windows clients can manipulate them. NT ACLs, too.
There was this interesting talk [1] about how this ISP uses OpenBSD as BGP control plane.
I used to heard that OpenBSD was often used as Internet facing middlebox (like firewalls/proxy/network load balancer) because of how good pf and relayd are.
But it would surprise me if it would still be the case nowadays, OpenBSD seems to perform poorly [2] in terms of network throughput compared to the competition (VyOS/VPP). And I don't think this 7.5 upgrade helped a lot regarding this topic.
Caught my eye. I'm vaguely aware that Theo de Raadt is not the paragon of modesty, but would still expect a more "communal" copyright. Or is OpenBSD largely a one-man show?
One would probably have to define "one-man show". But, no, Theo does not write most of OpenBSD's code. Although he certainly is the leader of the project. If the copyright statement bothers you, I can recommend the announcement e-mail (see "THANKS" in particular):
I believe that copyright notice is for organizing the layout of the actual distribution images (ISO, etc) and for the music and artwork (though work-for-hire), not that Theo de Raadt is claiming copyright over all of the code in the distribution.
The problem with having a benvolent dictator is that the system is set up for a dictator to control things, and the chances of the next dictator being quite as benevolent are low.
perhaps Theo has a plan for an eventual succession, perhaps not. Sometimes dictators can't really conceive of somebody else running the show so they don't plan for it.
The Linux kernel development model is one that embraces forking and submitting patching in a way that totally horrifies webdevs paid to mush together data transformation pipelines.
Linus and Greg KH are both very clear that you don't have to use their "blessed" source trees. You're encouraged to fork.
All of the genuinely moronic rhetorical arguments about "maintainer responsibility" are downstream from the GPLv2, which very clearly states in all capital letters there's no warranty implied or otherwise. The amount of time wasted on moot debates over that is mind boggling.
After he chewed out Intel for making such shitty CPUs, he was unceremonsiously removed from his position and sent away for a full month of re-education at an undisclosed location. This was shortly after Spectre and Meltdown became public. Feel free to read more about it!
Always interesting to see the amount of work going into LibreSSL, but I'm not sure how much use it gets outside of OpenBSD which seems a bit of a shame.
The removal of generic syscall(), and introduction of pinsyscalls() which registers the precise entry location of every system call used by a program, makes me think of some kernel-level ABI issues that Linux has.
In particular, kernel ABI is the main stable interface that Linux exposes - and all applications can just use syscalls directly without having to interface with the libc at all. However, that means that kernel must not change its ABI lest it risks breaking compatibility, and each functionality that isn't implemented inside of the kernel (e.g. GUI stuff) cannot be implemented completely portably.
However, using pinsyscalls(), a kernel can make sure that syscalls can only be called from the libc - therefore, making the libc de-facto ABI! Which allows for much more freedom in changing kernel ABI, as long as the libc follows through. Perhaps this way the system can go away from the syscall-level ABI and move over to the libc ABI / shared library ABI?
Honestly, I think that making libc THE system interface is a mistake. Ok, I understand issues with the Linux approach of exposing raw syscalls (though it works well enough in practice and ossification could be amended by some kind of syscall versioning scheme), but why in the world can't you introduce libsystem/libsyscall/libopenbsd which would contain only "syscall" functions? Why do you need all the C junk in a library for talking with OS?
UNIX is the C language runtime, so to speak, so naturally libc is THE system interface.
It only became something else, when C got standardised, a tiny subset of it landed into ISO C, grew beyond UNIX, and the rest of the UNIX API surface landed at Open Group's POSIX.
Obviously on the UNIX world nothing changed, until GNU/Linux came into scene and decided to act in another way, due to being GNU ecosystem + Linux kernel combo.
I do not dispute that it made sense during early days of UNIX. But today we write system software for these operating systems in many languages other than C. Maybe it's time to reconsider the dominant libc position instead of reinforcing it further?
Linux has successfully paved the way and demonstrated its practicality. Yes, it made certain unfortunate mistakes along the way, but OpenBSD (or any other OS) can learn from those and provide a better solution.
Every other operating system does exactly the same in regardless to abstracting syscalls, regardless of being UNIX clone or not, GNU/Linux is the exception, not the rule.
If you mean a C based OS ABI, there are many other alternatives, like on managed OSes, IBM and Unisys surviving mainframe and micro computers, OS IPC like COM/XPC/AIDL/FIDL/D-BUS.
Nothing stops you from making your own libsystem. Or still just making syscalls.
Nobody seems to understand how this feature works, even though it's quite simple. The process asks the kernel to only allow system calls from one segment. If you don't like that, don't ask for it.
A "stable" syscall ABI means that the interface between kernel and userland is ossified, potentially forever. If OpenBSD did this, then many of the security improvements it has made over the years, which has required the deletion of old (bad) system calls and the modification of other system calls to make them safer, never could happen without fundamentally breaking userland.
Calling into system calls in libc is not a hindrance at all for the use of other languages, any more than calling directly into a syscall would be. Cross-language function calls have been a time honored tradition since the first compilers were developed.
Linux's ossified syscall ABI is a quirk of Linux, and not a feature found in most, let alone many, operating systems.
> Calling into system calls in libc is not a hindrance at all for the use of other languages, any more than calling directly into a syscall would be.
I would say that it is a hindrance though. It's a hindrance even for relatively straight forward C code. You cannot for example use clone and expect the libc to continue working.
These libraries are the problem, not the solution. They're full of static global data which will get clobbered whenever you do anything more complicated than I/O. They use thread local variables for returning errors codes. It's bad legacy stuff.
Bullshit. A stable syscall api reflects a well designed kernel interface. You can obviously extend on it and deprecate at your will. Thing is, call gates are quite more common now (they even have shortcut instructions in modern cpus) vs software interrupts (int80h), and there is quite some effort into of runtime linking vs static linking - yes, static linking can be used in libc-based ABIs but just defeats the purpose. In my opinion, libc should not be a broker for privileged operations. There are a plethora of reasons for this, but the most obvious is that languages may not use libc in their linkage.
And FFS, Ive been using OpenBSD for well over 2 decades now. I'd say any syscall changes done in the OS are minimal compared to eg. linux.
> Bullshit. A stable syscall api reflects a well designed kernel interface.
Says who? I certainly wouldn't consider Linux's syscall ABI to be well designed. You know what is well designed? A stable facade that provides minimal overhead between two components, which prevents tight coupling. Like libc.
> You can obviously extend on it and deprecate at your will.
Only by breaking userland, which grinds this process to a crawl, even when it can happen at all. libc provides a better interface here.
> Thing is, call gates are quite more common now
I fail to see the relevance here. The mechanism by which syscalls are made doesn't make it cheaper to ossify your syscall ABI, nor does it improve security. It can certainly reduce the performance hit of a context switch. But, even with call gates, the overhead of a context switch is so high that adding the overhead of calling a wrapped function in libc is hardly going to matter.
> and there is quite some effort into of runtime linking vs static linking
What effort? Yeah, you have ld.so doing the relocation for you at runtime, but this happens once at program load time. Compared to everything else that must occur to load a program, dynamic linking adds minimal overhead.
> In my opinion, libc should not be a broker for privileged operations.
That's an interesting opinion, but beyond an unlisted "plethora of reasons", I don't see any relevant reason for this blanket ban. Having a single path into and out of the system call interface provides a way in which userland protections -- such as syscall pinning, immutable pages, etc., can be added. For defense in depth, this is useful.
> but the most obvious is that languages may not use libc in their linkage.
How does language runtime library linkage matter? What is the real difference to a language whether it calls read() or the read syscall? Either way, it has to marshal arguments through a FFI. Either way, it has to do the same amount of work. Languages must be ported to each operating system they run on. On OpenBSD and MacOS in particular, this porting means calling libc. On most OSes, libc is considered the preferred interface. On Linux, it's not, and because of that, folks assume that Linux's relative uniqueness here is somehow the default.
There is really no point to directly using syscalls. In nearly every case for unistd, socket, and fcntl, the libc wrapper is negligible. You can do all of the same things. There are few, if any, enforced C-isms. Even where they exist, they can be abstracted with a middling to average FFI library. Performance-wise, the significant overhead is making the syscall. Calling a library to do this has little measurable effect.
> You know what is well designed? A stable facade that provides minimal overhead between two components, which prevents tight coupling. Like libc
Actually, opposed to libc. Minimal overhead means either pass by register values or using call gates to copy stack frames. Libc just adds a new layer of cruft.
>Having a single path into and out of the system call interface provides a way in which userland protections -- such as syscall pinning, immutable pages, etc., can be added.
None of those are libc-specific, and can also be implemented using privileged kernel implementations. So, nothing new.
>How does language runtime library linkage matter? What is the real difference to a language whether it calls read() or the read syscall? Either way, it has to marshal arguments through a FFI.
The level of indirection. If there is no real difference, why not use the syscall directly? Why use yet another layer of crap to - in the end - perform a call by register?
> Languages must be ported to each operating system they run on.
One thing us the language,another is the runtime. The runtime should be as agnostic as possible, and that actually means using syscalls, not a given libc version.
> There is really no point to directly using syscalls. In nearly every case for unistd, socket, and fcntl, the libc wrapper is negligible. You can do all of the same thing.
You are right, they are almost the same thing. Thats one more motive to skip libc completely, because adds little to nothing no non-c languages.
> There are few, if any, enforced C-isms.
Such as struct (lack of) alignment, string formats and call conventions. Few, but relevant.
So, your argument essentially boils down to "call it something other than libc". Because, most of the syscall integration in libc has little if anything to do with C.
Eh. Whatever. Call it libunix if you prefer. If you want, you can literally strip libc of anything you don't like, call it libunix, and OpenBSD's ld.so mechanics will gladly pin syscalls to that.
My argument boils down to "there are other views onto implementing userspace runtimes other than the libc view", and "general purpose operating systems should not demand everyone use their own language-specific userland runtime implementation just because its what their favourite language uses".
You were the one trying to justify that layer as a de-facto ABI interface. For some things, it is not actually necessary and - in my opinion - should not be the target as a system ABI compatibility. Its a bit like saying "MSVC++ Runtime should be the de-facto runtime for every Windows application". There is a clear distinction between having a posix-compatible POSIX system (which targets source-code portability, focused mainly on C as the lowest common denominator) or a System V compatible system that provides POSIX compatibility.
> Eh. Whatever. Call it libunix if you prefer.
It is not not "whatever". A language-specific library should not - in principle - be a core dependency of every userland application on a general purpose UNIX system; A given language may implement its own runtime, as well as provide pure statically linked binaries. You may have a different opinion, but it seems a bit childish to discard the fact that not only there are use cases, but this has been somewhat of a problem in the past just because you don't agree with it. No one is stopping you from using libc.
You want to impose your Linux-centric view of ossified syscall ABIs on the world. That's just not reality on any other operating system other than Linux, nor should it be.
libc is the standard, but there is nothing that prevents you from hacking up libc to make some Frankenstein library that makes you feel better about "avoiding C" for whatever that's worth. Somehow, you think that libc is making your language runtime worse because it's written in C. Somehow, you think that writing an FFI -- as most high level languages do -- into libc is an inconvenience. It will probably blow your mind to realize that most operating systems, and thus most syscall interfaces, are also written in C. :-)
Then you compare libc to the MSVC++ runtime for some odd reason. And yet, if you do write applications that target Windows, you use their system libraries, which are predominantly written in C and provide C functions, regardless of the high level language you choose. These libraries implement the interface to the kernel, much like most operating systems other than Linux.
> You want to impose your Linux-centric view of ossified syscall ABIs on the world. That's just not reality on any other operating system other than Linux, nor should it be.
Actually, its not linux-centric, its System V-centric. And there is no ossification - at least not more than you have on what you're defending - a standard userland ABI runtime. I'm assuming you actually never used older systems - syscall/interrupt-based/call gate based is actually the "the facto standard", not whatever libc-based system you're running.
I also find it amusing you keep talking about linux. Did Linus eat your homework or something? For me it is quite odd, specially considering I've been using OpenBSD since 2.9, FreeBSD since 4.3 and only somewhat recently use linux as a main unix-compatible environment.
> libc is the standard
Says you and nobody else. Case in point, the problem is with a runtime that IS NOT libc-based, and should be supported, because it is targeting a SPECIFIC OS VERSION and not a libc version. Btw, that's why OpenBSD has its support cycles measured in releases, and not libc versions, but I'm assuming you are completely aware of this.
> Somehow, you think that writing an FFI -- as most high level languages do -- into libc is an inconvenience. It will probably blow your mind to realize that most operating systems, and thus most syscall interfaces, are also written in C. :-)
Yes, we - the rational people that think a general-purpose operating system should not be dictating runtimes onto users - we are all stupid, and we never did any OS-related development. We also fail to realize that C is basically the lowest common denominator, that's why its used as a semi-stub language for machine-level stuff. We are very very stupid here in the land "we are not you". Is that it?
> And yet, if you do write applications that target Windows, you use their system libraries, which are predominantly written in C and provide C functions, regardless of the high level language you choose
Well, yes and no. Last time I checked, any 32 bit assembly application using int 21h is honored (haven't tested it on 64 bit), ~40 YEARS ON. Same goes for DPMI calls. That's the "syscall layer" for you. You may also be surprised to find out that Windows is actually a sort of hybrid microkernel (such as macos X family, btw), so you can actually provide a lot more "core functionality" as part of the base OS, such as audio mixing or graphics primitives. and you can use the "fancy approach" and use an available runtime (MSVC++ IS an example of a runtime similar to libc), or use your own.
The last semi-monolithic version of it was Windows ME, and the lowest common denominator for operation is - you guessed it - system interrupts. Your console app developed in 1999 in Windows ME should run fine on a modern Windows version, as it will your OpenBSD console app, as long as you don't depend on libc. In fact, your 1983 MSDOS app should have no problem running in a fairly recent version of Windows without any kind of emulation whatsoever, except for the v86 wrapping mode.
Oh and no, I'd say most windows core libraries are C++, not C. And even there, they're trying to get rid of it for - AT LEAST - 20 years - many internal services in Longhorn were C#. Things evolve, and the sooner we get rid of the C heritage, the better.
> These libraries implement the interface to the kernel, much like most operating systems other than Linux.
Your simplistic view of operating systems based on what OpenBSD is amuses me. As an example, feel free to ping me back when your userland kernel ABI actually implements useful stuff like a unified audio interface (or linux, since you mention it so much). Or volume management. Or actually unified printing experience. You know, all the stuff you actually get from microkernel or hybrid-based kernels that you DON'T have in monolithic kernel design. Have libc doing something that isn't either a runtime library for your specific language or a syscall and you may have a point. Until then, its actually quite more restrictive than using int-based syscalls.
> I'm assuming you actually never used older systems - syscall/interrupt-based/call gate based is actually the "the facto standard"
Actually, my code runs just fine on older versions of Unix, because it uses libc and doesn't attempt to use interrupts, call gates, or whatever hidden interfaces varying between minor releases or different hardware revisions, were available on a specific version and a specific kernel compilation.
> Case in point, the problem is with a runtime that IS NOT libc-based, and should be supported, because it is targeting a SPECIFIC OS VERSION and not a libc version.
The compiled runtime may be specific to a particular libc / *nix version, but the source code is typically agnostic. Detect what it needs and trust the compiler to fill in the details. Or, of course, you could have conditional compilation and custom code for every minor release and *nix flavor out there. Clearly, no, that's not typical.
> and the sooner we get rid of the C heritage
Ah, we get to the crux of the issue. You actually believe that it is language and not engineering process and tooling, that somehow influences safety and security.
> Your console app developed in 1999 in Windows ME should run fine on a modern Windows version...
You're describing something that's more of a bug than a feature. Windows' binary backwards compatibility has been a source of many security vulnerabilities and instances of flaky behavior caused by regressions in the emulation layer. And, yes, it's an emulation layer at this point more than it's an interface or API.
I'll skip the weird strawman about how building portable applications backed by libc is somehow an OpenBSD-ism.
Software interrupts are glacially slow. You may want to familiarize yourself with modern hardware and syscall traps. These may work similarly to a software interrupt, but they have much better performance, even when pinned to libc, libunix, or whatever other library you use instead of littering your code with explicit trap instructions.
I think the main concern about libc is that there are many aspects of it that aren't "minimal", so developers who want an interface for syscalls only are pressured into using libc in its entirety. I do not think libc is currently well designed either.
For GNU libc, I would agree. But, not all libc implementations are equal.
OpenBSD has spent a lot of time sanitizing their libc implementation, and they have even split their static C runtime library to further reduce its footprint.
Developers are only really penalized for what they use. read, write, socket, bind, close, open, mmap, etc., really aren't that complex. Already, that's a significant portion of the libc footprint that any other language would use.
I personally see little reason why libc couldn't be further minimized into a libunix that just contained the syscall interface. It doesn't make much of a difference really, but perhaps it would shift the largely misplaced unease that many developers have regarding anything involving C.
Do you know what Unix is or the C programming language? Your bafflement is entirely baffling. OpenBSD is never switching to Rust or Go or any of the new fad languages, so why not use libc? It’s the Unix way after all.
True, but making it de-facto ABI (by making syscalls impossible outside of the libc) would solve the problem of programs breaking on kernel breaking change.
