X86_64-unknown-linux-unknown?

For at least the open-development BSDs, that's something that could change, at least in principle, and "safe code all the way down to the actual syscall instruction" might be enough of a reason to persuade them. Even if they don't want to stabilize the ABI to the extent that Linux does, they might be interested in providing a thin, language-agnostic "libsys" that doesn't have all of C's baggage. (The challenge is of course figuring out exactly where to draw the line between "useful generic stuff" and "baggage".)

4 Likes

...so an attacker has to prove knowledge of one 64-bit secret?
Would it be same level of security If they required it be placed into a register?

best hope I guess, realistically

1 Like

It makes sense as an additional defensive measure. Probably intended more to close an avenue for ASLR bypass, than as a security boundary in itself.

It occurrs to me that this might be more interesting to *BSD core developers if coupled with stable, language-generic ABI for Result<T, E> where T is a scalar, raw pointer, or () and E is a small positive integer. This would mean that libsys could have a stable ABI that didn't involve errno, eliminating a major reason why it would need to know about threads.

You have essentially already almost completely designed it just now haven't you? :slight_smile:

...if you just want to get rid of errno it could also be done in a less generic way, on a function-by-function basis, right? Then you don't need to decide once and per all the functions who allocates memory, what ownership rules are etc.. This can then be chosen separately for each function.

The hard part is the stability guarantee, I would think.

Yeah—that's essentially what's been done with the pthreads functions that return an error code and put useful return data in out-parameters—but I think the hypothetical value of this libsys to the core BSD devs would be in the genericity. "Here is a straightforward way you can write a DLL, in whatever language you prefer, that exposes a stable low-level interface to the kernel in a way that all the up-and-coming new languages that don't want the C runtime can use. So you only have to do this work once."