4 ms·

Hm, I thought there was some issue with glibc not wanting to provide wrappers for certain Linux syscalls. What if the Go runtime wanted to use one of those sysc

• quotemstr 7y ago
  Yes, it'd have to bypass libc for those system calls, just like any C program would. How is that an excuse for bypassing libc for things like read(2)? No, making system call interposition harder isn't a security feature. A user who can LD_PRELOAD you can already do arbitrary things to your program.
  • jart 7y ago
    Sometimes when folks talk to the kernel, they want to know they're talking to the actual kernel. glibc by design lets random stuff on the system MiTM symbols like read (even security critical ones like getrandom) and the LGPL effectively forbids many projects from using static linking as an escape hatch. The Chrome guys had to write a whole system call library from scratch because of it. On Windows it tends to get much more intense, where dynamic symbol interposition is brought to its logical conclusion, and you've layers upon layers of antivirus hooks and spyware sitting between you and the system. There, pretty much the only thing you can do is just SSL the heck out of everything.
    • dooglius 7y ago
      > glibc by design lets random stuff on the system MiTM symbols like read Can you elaborate on this? I'm aware of things like LD_PRELOAD, but if an adversary controls the environment, he could just change PATH to point to a rooted version of chrome anyway. That also has to do with the capabilities of the system linker, not glibc. >the LGPL effectively forbids many projects from using static linking as an escape hatch The LGPL explicitly allows static linking, that's the main difference versus the GPL.
      • jart 7y ago
        Are you in control of your network connection? Packets aren't that much different from calls between DSOs. It's just a big onion ring. If you make a conscious decision to trust Chrome with your data, then does Chrome have a moral obligation to ensure that choice, in reality, ends up being You<->Chrome, rather than You<->SysAdmin<->Comcast<->NSA<->Hacker<->Chrome? Or maybe they just want to protect IP holders. Or maybe they just don't want folks filing bugs about performance when the root cause turns out to be some poorly written system library. At the end of the day, it's all about minimizing unknowns. LGPL allows dynamic linking. Only way it'll allow static is if your releases are accompanied by tools for decompiling and recompiling your binaries with the LGPL bits interchanged. But that actually might not be allowed either, since GCC 4.3+ headers and runtimes (e.g. libstdc++) kind of prohibit you from changing binaries on your own, after they've been compiled.
        • a1369209993 7y ago
          > But that actually might not be allowed either, since GCC 4.3+ headers and runtimes (e.g. libstdc++) kind of prohibit you from changing binaries on your own, after they've been compiled. Can you elaborate on this?
          • jart 7y ago
            Read the GCC Runtime Exception v3.
        • cesarb 7y ago
          > Are you in control of your network connection? Packets aren't that much different from calls between DSOs. The difference is that calls between dynamic libraries are on the same side of the "airtight hatchway" (as explained by Raymond Chen at https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...), while there's a security boundary at the network connection.
          • jart 7y ago
• duskwuff 7y ago
  glibc has a fallback in the form of the syscall() function, which can be used to invoke any syscall without the need for a wrapper, e.g. syscall(SYS_getcpu, &cpu, &node, NULL);
  • yjftsjthsd-h 7y ago
    How is that different from just calling it yourself?
    • duskwuff 7y ago
      It means you don't have to deal with the kernel's calling conventions, which are architecture-specific and require inline assembly.