5 ms·

The driving force for this was the syscall origin check, but syscall ABIs change too. There's a speculative execution bug in ARM CPUs which requires barriers. T

The driving force for this was the syscall origin check, but syscall ABIs change too. There's a speculative execution bug in ARM CPUs which requires barriers. This also requires patching. https://marc.info/?l=openbsd-ports-cvs&m=158083696719245&w=2 https://marc.info/?l=openbsd-ports-cvs&m=158083696719245&w=2

Flow 6y ago
> All except some of the most recent arm64 processors have a speculative execution flaw that occurs across a syscall boundary, which cannot be mitigated in the kernel. Big Ouch. I wonder how the Linux developers will approach this bug since they don't enforce syscalls to be done from glibc.
- spijdar 6y ago
  It's not enforced, but I'd dare say by and large almost everything will just use glibc. I'd assume if you're playing with fire enough to be calling syscalls yourself, you can mitigate the bugs yourself. I don't think it'll be a bit problem, anyway. In my experience not very much calls syscalls directly. Go is a big exception, though...
  - arghwhat 6y ago
    > It's not enforced, but I'd dare say by and large almost everything will just use glibc. What about musl? uClibc? Linux is well known for the fact that it guarantees its syscall interface as primary contract to userspace.
    - spijdar 6y ago
      Okay, so I'm referring mainly to the typical "GNU/Linux" desktop/server OS vs embedded or "container Linux" which is where the majority of alternative libc use will happen. In either case though there is a libc that most software will use, and the mitigations can be applied there. Even though direct use of syscalls is legal on Linux, the fact that it's stable is primarily relevant and interesting to said libc developers. The fact that syscalls aren't guaranteed on other systems is usually of little consequence since the libc is developed in tandem with the kernels of those systems. Linux's situation as a fully decoupled kernel means it does things differently in that sense. The developers are fully separated, so there needs to be a strong "contract" that syscalls will be stable. Doesn't mean (IMO) it's a good idea for end-users e.g. software developers to use syscalls except in exceptional circumstances. Which is usually the case!
      - Flow 6y ago
        Not sure what you are advocating here. If someone successfully injects code that perform a direct syscall they can successfully use this info leak despite a safe and patched (g)libc.
        TheDong 6y ago
        > If someone successfully injects code that perform a direct syscall they can successfully use this info leak despite a safe and patched (g)libc. As Raymond Chen wrote, that's the other side of the airtight hatch (https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...). If someone is capable of directly running their own code that ignores libc (or other existing mitigations, such as may exist in javascript runtimes / go compiler) then cool, they can use spectre to perform a timing attack against their own code that they're running. Or they could just read their own memory. Spectre's main risk was for reading other program's memory or for doing so remotely with javascript. If you can already make the process you're attacking run arbitrary syscalls instead of use glibc, then you've already won and no amount of protection will help.
        lxgr 6y ago
        > If you can already make the process you're attacking run arbitrary syscalls instead of use glibc, then you've already won and no amount of protection will help You're basically arguing that in a post-spectre world, native processes can fundamentally never be a security boundary again, right? I'm wondering if this is necessarily true. For the concrete example at hand, Linux could offer some opt-in mechanism, e.g. an argument to exec(), that restricts syscalls to glibc only. A sandboxing mechanism could then require all executed processes to go through glibc and instantiate them only using that option.
      - deleted 6y ago
        [deleted]
      - arghwhat 6y ago
        On Linux, libc developers are in the exact same group as regular developers. libc is not intended to be the official entry point in any way or form, and kernel vulnerabilities and workarounds are not meant to be handled by a libc implementation. That other OSs make libc their official interface is primarily because it's the simplest thing to do when kernel, libc and the rest of userspace is co-developed, as it allows for breaking kernel changes and other fun things that are not allowed under Linux ABI guarantees anyways. It is not because it is the most secure choice, or that dealing with syscalls is hard (syscalls are easy and safe to work with). It's just that stable ABIs are a lot of work to develop, and this structure is just the simplest for smaller OS communities to develop.
  - bregma 6y ago
    Android is not GNU/Linux. There are an awful lot of Android computers out there. Embedded Linux is almost never GNU/Linux. There's an awful lot of embedded Linux out there. Desktop Linux is hardly the majority of Linux installations. How many containers in the cloud are using something like Alpine Linux? I'd dare say by and large glibc is in the minority.
  - deleted 6y ago
    [deleted]
- the8472 6y ago
  > will approach this bug Note that the mail is from 2020. So it probably already is fixed. It might be this one https://patchwork.kernel.org/project/linux-arm-kernel/patch/1543322517-470-3-git-send-email-will.deacon@arm.com/ https://patchwork.kernel.org/project/linux-arm-kernel/patch/...
prepperdev 6y ago
vDSO is a good way to mitigate issues like these. It's also a better stable ABI than libc, and easier to maintain than pure kernel ABI (like Linux does), because nobody forbids the kernel to inject different vDSOs to different binaries, if a need arises. vDSO is also a language independent construct, so there's no special treatment for any favorite language, be it C (OpenBSD), C++ (Windows) or Oberon OS (Oberon). vDSO: https://en.wikipedia.org/wiki/VDSO https://en.wikipedia.org/wiki/VDSO
- remexre 6y ago
  vDSO functions are still allowed to use arbitrary amounts of stack though, which means Go might still have problems with them without having to allocate much larger stacks than it normally would.
  - masklinn 6y ago
    In fact that is an issue Go hit in the past: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
  - prepperdev 6y ago
    That would be up to a specific OS to decide which guarantees on stack size limit would it like to provide. But I agree that it's a valid concern, and not all possible vDSO implementations are reasonable.
lxgr 6y ago
For anyone wondering what the syscall origin check is about or how it's implemented: https://lwn.net/Articles/806776/ https://lwn.net/Articles/806776/ Seems like this is a good idea for multiple reasons. Another benefit is that it would seem to make something like "Wine in reverse" possible/easier to implement.
- severino 6y ago
  Can you please elaborate on this "Wine in reverse" concept?
  - lxgr 6y ago
    I'm talking about a userspace-only Linux compatibility layer for Windows. As far as I understand, Wine (a userspace-only Win32 emulator) is possible because Windows applications always go through the standard library for system calls, which therefore can be hooked without kernel support. The same is not generally true for Linux binaries – these usually do go through glibc, but direct syscalls are possible (through raising the appropriate interrupt or instruction). I don't think there's an easy way to trap these without kernel support (which is what WSL 1 has been doing).
    - masklinn 6y ago
      > The same is not generally true for Linux binaries – these usually do go through glibc, but direct syscalls are possible (through raising the appropriate interrupt or instruction). OTOH Linux having a well defined set of syscalls you can very convincingly fake being a Linux kernel. That’s what wsl1 did. That’s also what SmartOS does, which allows it to mix native and Linux (LX) zones.
      - lxgr 6y ago
        Definitely, iSH does the same thing on iOS and it works really well. But I don't see why we can't have both (a stable syscall interface and requiring all syscalls to go through a standard library).

Flow 6y ago

> All except some of the most recent arm64 processors have a speculative execution flaw that occurs across a syscall boundary, which cannot be mitigated in the kernel. Big Ouch. I wonder how the Linux developers will approach this bug since they don't enforce syscalls to be done from glibc.

spijdar 6y ago
It's not enforced, but I'd dare say by and large almost everything will just use glibc. I'd assume if you're playing with fire enough to be calling syscalls yourself, you can mitigate the bugs yourself. I don't think it'll be a bit problem, anyway. In my experience not very much calls syscalls directly. Go is a big exception, though...
- arghwhat 6y ago
  > It's not enforced, but I'd dare say by and large almost everything will just use glibc. What about musl? uClibc? Linux is well known for the fact that it guarantees its syscall interface as primary contract to userspace.
  - spijdar 6y ago
    Okay, so I'm referring mainly to the typical "GNU/Linux" desktop/server OS vs embedded or "container Linux" which is where the majority of alternative libc use will happen. In either case though there is a libc that most software will use, and the mitigations can be applied there. Even though direct use of syscalls is legal on Linux, the fact that it's stable is primarily relevant and interesting to said libc developers. The fact that syscalls aren't guaranteed on other systems is usually of little consequence since the libc is developed in tandem with the kernels of those systems. Linux's situation as a fully decoupled kernel means it does things differently in that sense. The developers are fully separated, so there needs to be a strong "contract" that syscalls will be stable. Doesn't mean (IMO) it's a good idea for end-users e.g. software developers to use syscalls except in exceptional circumstances. Which is usually the case!
    - Flow 6y ago
      Not sure what you are advocating here. If someone successfully injects code that perform a direct syscall they can successfully use this info leak despite a safe and patched (g)libc.
      - TheDong 6y ago
        > If someone successfully injects code that perform a direct syscall they can successfully use this info leak despite a safe and patched (g)libc. As Raymond Chen wrote, that's the other side of the airtight hatch (https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...). If someone is capable of directly running their own code that ignores libc (or other existing mitigations, such as may exist in javascript runtimes / go compiler) then cool, they can use spectre to perform a timing attack against their own code that they're running. Or they could just read their own memory. Spectre's main risk was for reading other program's memory or for doing so remotely with javascript. If you can already make the process you're attacking run arbitrary syscalls instead of use glibc, then you've already won and no amount of protection will help.
        lxgr 6y ago
        > If you can already make the process you're attacking run arbitrary syscalls instead of use glibc, then you've already won and no amount of protection will help You're basically arguing that in a post-spectre world, native processes can fundamentally never be a security boundary again, right? I'm wondering if this is necessarily true. For the concrete example at hand, Linux could offer some opt-in mechanism, e.g. an argument to exec(), that restricts syscalls to glibc only. A sandboxing mechanism could then require all executed processes to go through glibc and instantiate them only using that option.
    - deleted 6y ago
      [deleted]
    - arghwhat 6y ago
      On Linux, libc developers are in the exact same group as regular developers. libc is not intended to be the official entry point in any way or form, and kernel vulnerabilities and workarounds are not meant to be handled by a libc implementation. That other OSs make libc their official interface is primarily because it's the simplest thing to do when kernel, libc and the rest of userspace is co-developed, as it allows for breaking kernel changes and other fun things that are not allowed under Linux ABI guarantees anyways. It is not because it is the most secure choice, or that dealing with syscalls is hard (syscalls are easy and safe to work with). It's just that stable ABIs are a lot of work to develop, and this structure is just the simplest for smaller OS communities to develop.
- bregma 6y ago
  Android is not GNU/Linux. There are an awful lot of Android computers out there. Embedded Linux is almost never GNU/Linux. There's an awful lot of embedded Linux out there. Desktop Linux is hardly the majority of Linux installations. How many containers in the cloud are using something like Alpine Linux? I'd dare say by and large glibc is in the minority.
- deleted 6y ago
  [deleted]
the8472 6y ago
> will approach this bug Note that the mail is from 2020. So it probably already is fixed. It might be this one https://patchwork.kernel.org/project/linux-arm-kernel/patch/1543322517-470-3-git-send-email-will.deacon@arm.com/ https://patchwork.kernel.org/project/linux-arm-kernel/patch/...

prepperdev 6y ago

vDSO is a good way to mitigate issues like these. It's also a better stable ABI than libc, and easier to maintain than pure kernel ABI (like Linux does), because nobody forbids the kernel to inject different vDSOs to different binaries, if a need arises. vDSO is also a language independent construct, so there's no special treatment for any favorite language, be it C (OpenBSD), C++ (Windows) or Oberon OS (Oberon). vDSO: https://en.wikipedia.org/wiki/VDSO https://en.wikipedia.org/wiki/VDSO

remexre 6y ago
vDSO functions are still allowed to use arbitrary amounts of stack though, which means Go might still have problems with them without having to allocate much larger stacks than it normally would.
- masklinn 6y ago
  In fact that is an issue Go hit in the past: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
- prepperdev 6y ago
  That would be up to a specific OS to decide which guarantees on stack size limit would it like to provide. But I agree that it's a valid concern, and not all possible vDSO implementations are reasonable.

lxgr 6y ago

For anyone wondering what the syscall origin check is about or how it's implemented: https://lwn.net/Articles/806776/ https://lwn.net/Articles/806776/ Seems like this is a good idea for multiple reasons. Another benefit is that it would seem to make something like "Wine in reverse" possible/easier to implement.

severino 6y ago
Can you please elaborate on this "Wine in reverse" concept?
- lxgr 6y ago
  I'm talking about a userspace-only Linux compatibility layer for Windows. As far as I understand, Wine (a userspace-only Win32 emulator) is possible because Windows applications always go through the standard library for system calls, which therefore can be hooked without kernel support. The same is not generally true for Linux binaries – these usually do go through glibc, but direct syscalls are possible (through raising the appropriate interrupt or instruction). I don't think there's an easy way to trap these without kernel support (which is what WSL 1 has been doing).
  - masklinn 6y ago
    > The same is not generally true for Linux binaries – these usually do go through glibc, but direct syscalls are possible (through raising the appropriate interrupt or instruction). OTOH Linux having a well defined set of syscalls you can very convincingly fake being a Linux kernel. That’s what wsl1 did. That’s also what SmartOS does, which allows it to mix native and Linux (LX) zones.
    - lxgr 6y ago
      Definitely, iSH does the same thing on iOS and it works really well. But I don't see why we can't have both (a stable syscall interface and requiring all syscalls to go through a standard library).