The Cosmopolitan Libc project has a very modest scope that isn't nearly as big as you suppose. We only support x86-64. We're not trying or claiming to be the ones who will carry the pledge() burden for the whole Linux world like glibc and Musl too, even though (so far) our implementation seems to do a reasonable job at that.

As for the moving target of the Linux system call ABI, we mostly use a whitelist model so I don't see why it should matter. Unless your concern is that we keep up with the latest new features. My humble opinion is there's very few system calls Linux has introduced in the last ten years that I personally care about using. Other people might care about things like io_uring and statx() but I tend to stick with the classic calls.

Keep in mind, Cosmopolitan Libc binaries are designed to run on six operating systems. I'm probably the only person on earth who's written a libc for that many platforms. Here's what I learned. If you look at https://github.com/jart/cosmopolitan/blob/master/libc/sysv/s... you can see that there's a point in history where consensus between systems drops off. It probably happened sometime around the year 2000, and since then Linux has mostly just gone its own way as far as UNIX systems are concerned. There's only been a select few system calls introduced in the last twenty years that every single system was quick to adopt, e.g. getrandom(), pipe2(), openat(), fstatat(), etc.

So I really don't think it's as complex as folks here are making it out to be. It's simply a question of focus. We aren't solving every problem. But the few things we are doing, we do very well.

I'll admit to not knowing this context around it, but I guess yes if you only support binaries linked against your own libc (and only dynamically), and only on one architecture, then it should work.

But as you say, it's quite limiting for userspace trying to use things that maybe your libc is not aware of.

Compare how OpenBSD is actually disallowing syscalls outside of their libc. That's the level of control that's needed both for it to work, and I don't think Linux lets you do that.

My point is: No, this does not "port pledge() to Linux". I'm sure you agree that it has many many asteriskses, to the point that the title built up a hope it can't live up to.

I wish it did, but I don't see it.

> We aren't solving every problem.

It's a good effort. But the problem isn't the narrow scope. The problem is "Porting OpenBSD pledge() to Linux", which I don't think is an accurate description of what this does.

> Compare how OpenBSD is actually disallowing syscalls outside of their libc.

And Cosmopolitan Libc actually disallows syscalls to the OpenBSD Libc whilst running on OpenBSD. If this surprises you then you've misunderstood the intent behind msyscall(), which Cosmopolitan's pledge() implements on Linux too. See the "Syscall Origin Verification" section of the blog post https://justine.lol/pledge/#msyscall The basic idea is you can choose whatever set of system call wrappers you want, put them into one memory location, and then the kernel will check the RIP register to make sure that SYSCALL is only being used from those addresses. Their choice to start doing this is kind of funny because it turns C libraries into a game of Highlander. There can be only one.

The only libc in the address space is a very attractive ROP target :)

Syscall origin verification is orthogonal to pledge and is not really even a security feature at all without strong CFI. The general consensus right now is that strong CFI is kind of a mythical unicorn that doesn't exist. pledge remains useful even though this is true, so syscall origin verification is not a prerequisite.

Yeah I said "compare" just as an illustration of the control that OpenBSD can and does exercise over the interface between user space and kernel space.

Yeah, that is true. IMO seccomp is kind of not useful unless you own the libc.