4 ms·

This is interesting. Although, I think it's always useful to point out that runtimes that directly make system calls will have portability issues in other *nix

This is interesting. Although, I think it's always useful to point out that runtimes that directly make system calls will have portability issues in other *nix systems. For instance, OpenBSD has recently restricted system calls to a single offset of their libc in order to reduce ROP attacks. If Lone wishes to be portable, it will need to consider a libc dependency as an option. If not, it can probably get away with direct syscalls on Linux unless Linux kernel developers decide to add support for pinning system calls. I doubt that this would ever be a hard requirement in the kernel, as it would break userland all over, but I could see this being an option for certain distributions as a ROP mitigation. Many features like these flow from OpenBSD to other OSes.

edgyquant 3y ago
Considering the title and use case it seems to be intentionally pretty specific to Linux
- nanolith 3y ago
  Many projects start this way. But, as per my comment, the assumption that direct syscall support will be maintained in future Linux distros is also risky.
  - matheusmoreira 3y ago
    I worry about that risk as well. I assume that even if Linux were to introduce a mechanism for system call authentication, it would be something lone would be able to use to mark its system call primitive as allowed.
    - nanolith 3y ago
      Perhaps. To be fair, I'm not aware of anything on the horizon, other than the fact that OpenBSD has been showing off their pinning implementation. As long as you know it's a possibility, then the point of my original comment is met. Good luck on this project. I look forward to seeing it progress.
      - matheusmoreira 3y ago
        Thank you!
  - kwhitefoot 3y ago
    Why is it risky? Linus is adamant that the greatest sin is breaking userland.
    - nanolith 3y ago
      That's a subtle point though. The kernel can't change defaults that break userland, nor can it change or eliminate features that would cause a breakage in userland. But, the kernel can certainly add an optional feature, like syscall pinning, that distributions can enable -- in userland -- to restrict userland. We see this already with seccomp policies meant to restrict and potentially break userland programs that misbehave. All that Linus guarantees is that, by default, the Linux kernel has no regressions that impact user code. If distributions enable breaking changes through syscalls or sysctls, that doesn't violate any of the rules imposed on Linux. syscall pinning -- if that becomes a thing in Linux -- is something that distributions would enable in order to mitigate ROP attacks.
deleted 3y ago
[deleted]
Conscat 3y ago
I think this decision from OpenBSD will more likely discourage developers from even considering it a supportable platform for software that originates in Linux land.
- nanolith 3y ago
  Direct syscall access is not something that is guaranteed in Unix derivatives. Linux is rare in that it provides a stable syscall API. Source compatibility is often only guaranteed when linked against libc or an equivalent low-level runtime library.
  - eikenberry 3y ago
    And this is generally a bad pattern unless those libc equivalents are services you call (like syscalls) and not a library you have to import or FFI. Requiring importing a library, probably from another language, is not a good alternative to syscalls.
    - nanolith 3y ago
      A bad pattern according to whom? Most language runtime libraries import other system libraries as needed. For better or for worse, libc is typically considered to be a system library. It's something that every distribution or Unix flavor provides that is guaranteed to work within the POSIX standard for interfacing with the operating system. It's up to the distribution maintainers to make that happen, even if they tweak things to support syscall pinning or seccomp rules. Userland directly calling a stable syscall API is a rare thing outside of Linux, and there is no guarantee that it will last forever even in Linux given the latest attacks. With modern ROP mitigations like syscall pinning, it will in fact be more dangerous to make syscalls directly -- if allowed in your distribution -- than it would be to call the minimal footprint of libc required to bootstrap a high level language runtime. Of course, with special pleading, it could be possible for distribution or OS maintainers to carve out an exception for syscall pinning for a particular language runtime. Ask Go how that's going for their OpenBSD port.
matheusmoreira 3y ago
You're absolutely right, it is not portable to other operating systems. I have written about this portability and system call stability here on HN a few times, at some point I decided to compile all the information into a post on my website. https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls I started lone (and previously a liblinux library) in order to make applications directly targeting the Linux system call binary interface. I chose Linux precisely because it's the only one with a stable interface. I currently have no plans to make lone a portable programming language.

edgyquant 3y ago

Considering the title and use case it seems to be intentionally pretty specific to Linux

nanolith 3y ago
Many projects start this way. But, as per my comment, the assumption that direct syscall support will be maintained in future Linux distros is also risky.
- matheusmoreira 3y ago
  I worry about that risk as well. I assume that even if Linux were to introduce a mechanism for system call authentication, it would be something lone would be able to use to mark its system call primitive as allowed.
  - nanolith 3y ago
    Perhaps. To be fair, I'm not aware of anything on the horizon, other than the fact that OpenBSD has been showing off their pinning implementation. As long as you know it's a possibility, then the point of my original comment is met. Good luck on this project. I look forward to seeing it progress.
    - matheusmoreira 3y ago
      Thank you!
- kwhitefoot 3y ago
  Why is it risky? Linus is adamant that the greatest sin is breaking userland.
  - nanolith 3y ago
    That's a subtle point though. The kernel can't change defaults that break userland, nor can it change or eliminate features that would cause a breakage in userland. But, the kernel can certainly add an optional feature, like syscall pinning, that distributions can enable -- in userland -- to restrict userland. We see this already with seccomp policies meant to restrict and potentially break userland programs that misbehave. All that Linus guarantees is that, by default, the Linux kernel has no regressions that impact user code. If distributions enable breaking changes through syscalls or sysctls, that doesn't violate any of the rules imposed on Linux. syscall pinning -- if that becomes a thing in Linux -- is something that distributions would enable in order to mitigate ROP attacks.

deleted 3y ago

[deleted]

Conscat 3y ago

I think this decision from OpenBSD will more likely discourage developers from even considering it a supportable platform for software that originates in Linux land.

nanolith 3y ago
Direct syscall access is not something that is guaranteed in Unix derivatives. Linux is rare in that it provides a stable syscall API. Source compatibility is often only guaranteed when linked against libc or an equivalent low-level runtime library.
- eikenberry 3y ago
  And this is generally a bad pattern unless those libc equivalents are services you call (like syscalls) and not a library you have to import or FFI. Requiring importing a library, probably from another language, is not a good alternative to syscalls.
  - nanolith 3y ago
    A bad pattern according to whom? Most language runtime libraries import other system libraries as needed. For better or for worse, libc is typically considered to be a system library. It's something that every distribution or Unix flavor provides that is guaranteed to work within the POSIX standard for interfacing with the operating system. It's up to the distribution maintainers to make that happen, even if they tweak things to support syscall pinning or seccomp rules. Userland directly calling a stable syscall API is a rare thing outside of Linux, and there is no guarantee that it will last forever even in Linux given the latest attacks. With modern ROP mitigations like syscall pinning, it will in fact be more dangerous to make syscalls directly -- if allowed in your distribution -- than it would be to call the minimal footprint of libc required to bootstrap a high level language runtime. Of course, with special pleading, it could be possible for distribution or OS maintainers to carve out an exception for syscall pinning for a particular language runtime. Ask Go how that's going for their OpenBSD port.

matheusmoreira 3y ago

You're absolutely right, it is not portable to other operating systems. I have written about this portability and system call stability here on HN a few times, at some point I decided to compile all the information into a post on my website. https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls I started lone (and previously a liblinux library) in order to make applications directly targeting the Linux system call binary interface. I chose Linux precisely because it's the only one with a stable interface. I currently have no plans to make lone a portable programming language.