4 ms·

> 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

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

by Flow 6y ago

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