X86_64-unknown-linux-unknown?

[zackw]

@bjorn3

Whatever benefits [rsix without libc] provides for Linux, it can't provide them for other OSes as their syscall interface is not stable.

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".)

[atagunov]

@bjorn3

OpenBSD even checks that the syscall originated from a select few memory regions to ensure that an attacker has to find the address of the respective libc function

...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?

@zackw

they might be interested in providing a thin, language-agnostic "libsys"

best hope I guess, realistically

[zackw]

@atagunov

...so an attacker has to prove knowledge of one 64-bit secret?

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.

@atagunov

@zackw

language-agnostic "libsys"

best hope I guess, realistically

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.

[atagunov]

@zackw

stable, language-generic ABI for Result<T, E> where T is a scalar, raw pointer, or () and E is a small positive integer

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

@zackw

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

...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.

[zackw]

@atagunov

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

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

@atagunov

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?

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."