Yeah I know, I was really asking why OpenBSD did it that way. I don't think string-based arguments are easier to use. If it was a struct with a load of `bool` fields you'd get code completion, compile time type checking, built in documentation, discoverability, etc. Much easier!

You can't trivially extend structs in a kernel ABI (to be fair this is worse in Linux as there is more than one libc and many programs do raw syscalls bypassing the libc anyway -- though it can still be done[1]) but string APIs are simpler to use and upgrade. They can also be far more ergonomic in some cases.

The core issue is that userspace programs and libraries can be compiled using structs with the old size (in theory the libc can abstract this using symbol versioning but then the same issue lies within the libc) causing out-of-bounds memory accesses when the kernel tries to access the struct fields. There's also forwards-compatibility issues but bad memory accesses are marginally worse.

[1]: https://lwn.net/Articles/830666/

From the LWN article you linked:

>This mechanism works by marshaling parameters to a system call into a single C structure; a pointer to that structure and the size of the structure are passed as the parameters to the system call. That size parameter acts as a sort of version number.

Oh hey, that’s exactly how every WIN32 call works. I see an article from 2003 talking about why Windows is strict about the struct size parameter: https://devblogs.microsoft.com/oldnewthing/20031212-00/?p=41...

> You can't trivially extend structs in a kernel ABI

IMO the article you linked is evidence that this is trivial. Especially for syscalls that will only be called a few times in a process’s lifetime. I dunno why there’s so much bike shedding about this on the mailing list.

Edit: Ahh I didn’t realize you were the Aleksa mentioned in the article. I wish you good luck.

That Windows article gives a better argument than I ever could as to why putting the size in the argument list is better than in the struct. Some pre-openat2 Linux syscalls are designed in the same way. (Having no forwards nor backwards compatibility but still having struct size versioning really is an interesting design choice...)

But yes, it is relatively trivial -- my point was more that you can't just use a struct in the way the first comment suggested, you need to come up with some scheme (even if it seems trivial in retrospect).

As for the bike-shedding, that's LKML for you (though in fairness it is a bit of a tall order to try to come up with some enforceable API design rules in Linux -- syscalls with half-baked designs being added is less rare than one would hope, so clearly there's not an overarching design principle being applied already, though thankfully it's becoming pretty rare to see a completely borked syscall that clearly has no users being merged).

The kernel can easily version APIs using struct size, as long as new members are only appended. The libc function would pass the size of the struct to the syscall, or you could have pledge() itself be a macro that computes sizeof in the caller.

That is the exact solution described in the link I included in my comment (I am the "Aleksa" in that article). It is not entirely trivial (certain edge cases need to be handled) but it is entirely doable. But string arguments also work if you don't have complicated data parsing requirements.

I (obviously) prefer the extensible struct solution but there are downsides (and other solutions weren't an option for Linux anyway).

There's a great blog post[1] by one of the OpenBSD developers about why they did so. tl;dr using bitmasks necessitates namespaced enums/defines that take up horizontal space, strings are easier and don't need to go through the C pre-processor.

[1] https://flak.tedunangst.com/post/string-interfaces

Nice find. That article is highly unconvincing though and mostly argues against straw men.

> Although using strings subverts C’s already weak type checking, that’s probably not a major concern. One can screw up bit masks by using || in place of |. Or, as above, one can incorrectly pack the magic array. It’s usually much easier to visually audit a string than the C code used to plaster a dozen option together.

It's pretty easy to design an interface that is way way less error-prone than strings (especially ones full of single-letter differences!) and the visual auditing argument falls apart as soon as you have to `snprintf()` some string together from parts.

This code is way more readable, way less error prone, more discoverable, faster and more easily extendable than strings:

    auto config = make_pledge_config();
    config.read_path = true;
    config.stdio = true;
    pledge(&config);

You'd think security focused people would care about static type checking.

if you really care about static type checking, you probably wouldn't be using C

You probably would if you care about static typing and are working on a kernel syscall interface.

and yet they chose to use strings for their api, eh?

Well exactly. That's why it's so weird.

Nice! I would probably have used bitmasks in this situation, but as usual there is a reason behind the choice and I get the reasoning.

great find!

Probably because the ABI would change when a pledge is added

Not necessarily. You can pass a bitmask of an arbitrary length using char*.