Hacker News Reader

Comment by Reelin | Hacker News Reader

> We've been concerned about adding even one additional syscall entry point

I don't understand the need for such a severe "only libc syscalls ever" approach.

What would be the security concern with allowing syscalls only from preauthorized (ie msyscall(2)) regions, making initial region authorization opt-in (instead of opt-out), allowing the program to call msyscall(2) itself, and rejecting any statically linked (ie non-ASLR'd) regions for authorization?

View on HN

> I don't understand the need for such a severe "only libc syscalls ever" approach.

There's nothing severe about it. Most systems are exactly that: systems of which the kernel is only one part, syscalls are rarely if ever intended to be called directly nilly-willy.

The issue is that unlike windows unices have never enforced this.

Sorry, that generalization doesn’t hold water.

It makes sense for systems where libc is tightly coupled and coversioned with the kernel, e.g. BSDs, but Linux always relied on third-party C libraries and supported static binaries, etc.

You could argue that BSD made the mistake of intending to have a Windows-style C library compat guarantee but not enforcing it, but that was not in scope for Linux. The philosophy has always been syscall-level compat (and there are lots of famous threads with Linus re-enforcing this to others who would presume that things should be “fixed in user space”).

So it’s hardly reasonable to generalize based on some BSD concerns; Linux is WAI and represents the most common Unix-like system people use today by far.

There’s a pretty good argument that this level of compat, while the source of some problems, has also made other things much easier: consider container images that are bundled with their own system libraries. (You could certainly invent schemes to inject these libraries, but dealing with link and library level compatibility seems even more complex to deal with than system call-level compatibility.)

Darwin/macOS has the same rules as Windows and the BSDs--syscalls are private API--and it's extremely popular due to iOS. Linux is in fact the odd one out here.

There is a difference though: libSystem on Darwin is a very thin wrapper over the kernel syscalls; on the contrary, libc is a library that was designed for C, then standardized in POSIX, and has several layer of abstraction over kernel syscalls including many bad defaults that are universally recognized as wrong today (eg: libc’s created file descriptors will all inherit by default).

> (eg: libc’s created file descriptors will all inherit by default)

Isn't that the kernel default? Even if you use system calls directly, file descriptors still inherit by default.

I mean, theoretically (i.e. I have no idea if anything does this), you could have underlying system file descriptors, which did not inherit, then a mapping from "libc" file descriptors onto OS ones and some code in fork() to copy over any OS file descriptors that are exposed to libc-using code.

The mapping is the identity function and whether a descriptor is inherit or not is just a function of O_CLOEXEC / fcntl(FD_CLOEXEC) / some special fd types are always cloexec, such as kqueues on FreeBSD. Libc fds aren't special to the operating system in any way.

Yeah, libc's syscall wrappers just do what you tell them. If you don't pass O_CLOEXEC to the kernel syscalls, you get the inherit behavior. Libc's syscall wrappers don't change this in any way.

To the extent that Go's default for file descriptors today is !inherit (I'm unfamiliar, but if so, it's a good choice), the Go runtime must already add O_CLOEXEC to bare syscalls. There's no reason to believe it incapable of adding the flag to libc syscalls instead.

You can't do that atomically with libc. There's a short window in which the file descriptor will potentially be inherited, if another thread forks.

That's incorrect.

You are thinking of the older way, where fcntl(fd, F_SETFD, FD_CLOEXEC) must be used after open(), leaving a short window in which the file descriptor may be inherited.

The newer way passes the O_CLOEXEC to open() and there is no fcntl() call. This is atomic with respect to inheritability: The kernel returns a non-inheritable file descriptor to libc, and libc returns it to the application.

Other syscalls that return a file descriptor have similar flags, so they are atomic too.

These flags and behaviours are exactly the same, whether done by calling through libc as most programs do, or direct kernel syscalls bypassing libc, as Go and a few other programs do.

Unfortunately, you misunderstand how CLOEXEC works and how the Go runtime implements the feature you think libc lacks.

This syscall level behavior is POSIX-specified[1] since at least the 2008 edition[2]:

> O_CLOEXEC > If set, the FD_CLOEXEC flag for the new file descriptor shall be set.

What that means is, any C program or Go program that passes the O_CLOEXEC flag to open(2) on a POSIX 2008 conforming system (including Linux and the BSDs, for example), will atomically create the fd without inherit behavior. There is no "short window" and hasn't been for more than a decade. The Go runtime must use that flag to provide that property; there is no other way on these systems. Libc users are of course able to use the same flag.

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/o...

[2]: https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...

Go isn't obligated to use any libc APIs or abstractions other than those providing syscalls.

You're incorrect or maybe just misleading about libc created file descriptors inheriting, as stated. Either way, it is unrelated to using libc for syscalls vs bare machine traps.

I think it's mandated by POSIX standard; but even if I'm wrong, there's still the problem that libc doesn't allow to do that atomically, for instance. In general, it's an old interface that doesn't fully expose the full power of all modern syscalls.

Most libc you'd care to use are going to include functions like dup3. If they don't, it's probably because the system call isn't available either.

You're mistaken.

https://news.ycombinator.com/item?id=21740035

https://news.ycombinator.com/item?id=21740498

libc is a C runtime library, while kernel32 is not.

For Go on Darwin:

libSystem is now used when making syscalls on Darwin, ensuring forward-compatibility with future versions of macOS and iOS.

From https://golang.org/doc/go1.12#darwin

This is mentioned obliquely in the top-level comment for this thread:

> solaris/macos approach … of calling libc stubs

The plan for containers on Solaris, after rejecting injecting libc from the host, was to have users rebuild all containers after OS upgrade. Windows has to virtualise containers with an incompatible OS version. It is definitely less convenient than Linux.

OpenBSD does have somewhat different constraints and they seem to think this will work for them.

The iOS Simulator does something along these lines for macOS. When macOS is updated CoreSimulator rebuilds the dyld_sim shared caches because simulator runtimes pull in libsystem_kernel, libsystem_pthread, and libsystem_platform (which cover the core of the kernel’s ABI).

The plan for containers on Solaris, after rejecting injecting libc from the host, was to have users rebuild all containers after OS upgrade.

What containers are you referring to? Because this is definitely not how Zones work on Solaris.

There are two types of Zones in Solaris 11; "Kernel Zones" which run their own independent version of Solaris and "non-global Zones" which are automatically kept at the same version as the host.

Windows has to virtualise containers with an incompatible OS version.

Not as far as I'm aware. Windows Sandboxes don't work that way nor do other technologies I'm aware of. What are you referring to?

This was Docker containers, which were under development, and I think one version shipped.

Windows containers have to run under hyper-v for incompatible kernel versions.

> It makes sense for systems where libc is tightly coupled and coversioned with the kernel, e.g. BSDs, but Linux always relied on third-party C libraries and supported static binaries, etc.

Linux is not a system. Linux is a kernel, linux has distributions, it is not a single coherent system where the kernel and standard library are co-developed. That's the entire point I'm making.

> So it’s hardly reasonable to generalize based on some BSD concerns

It's not "some BSD concerns", it's pretty much every non-linux unix. What's not reasonable is generalising "syscalls are a perfectly fine interface" which is almost exclusively a Linux exclusivity. Or don't claim compatibility with anything other than linux, that's also a perfectly fine choice.

> There’s a pretty good argument that this level of compat, while the source of some problems, has also made other things much easier: consider container images that are bundled with their own system libraries.

Last time I checked, Go did not run exclusively on linux. If it did, raw syscalls would indeed not be a concern (though even then they try to have their cake and eat it, as e.g. they want to do raw syscalls yet benefit from vDSO, which has been an issue in the past because their assumptions did not hold: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/)

Windows did not enforce this either, and despite how bad of an idea it is, there have been software that do their own syscalls. Mostly tricky things like DRM or anticheat.

Still, I don’t think there’s anything wrong with letting an application mark part of its code safe for syscall execution, versus enforcing libc only. Seems like the exact same thing as the execute bit. Moreover, some systems genuinely have a stable syscall ABI - I think Linux would be considered one.

Linux is basically the only system that targets a stable syscall ABI, and that's basically due to being loosely coupled with all other parts of a Linux-based operating system.

> Windows did not enforce this either

Windows pretty much enforces it in the sense that syscall numbers can change between minor updates, so raw syscalls breaks extremely often.

> Moreover, some systems genuinely have a stable syscall ABI - I think Linux would be considered one.

Linux is not a system. It's a kernel, with userlands you can bolt on. That's why it has a stable syscall ABI: that's the only interface Linux can have if it intends to provide an interface.

Perhaps "strict" would have been a better word choice than "severe".

It does seem that there's a very reasonable security concern about doing so from +w+x memory, or from non-PIE regions, or without first explicitly authorizing the calling range.

My question still stands regarding what the security concern of opt-in PIE -w+x code making direct syscalls is.

Edit: (Of course I do understand that the BSDs (unlike Linux) do not guarantee a stable syscall ABI and as such performing them directly is strictly a bad practice.)

The issue is that unlike windows unices have never enforced this.

That's not true; Solaris and I suspect other *nixes of the past made it explicitly clear that libc was the interface for userland, not the kernel.

> syscalls are rarely if ever intended to be called directly nilly-willy.

I don't think this is true, at least on Linux.

On Linux, the system call interface¹ is the documented interface to user space. Even the commonly used vDSO² is a stable interface. This is important because it means the popular C libraries are not part of the Linux kernel interface. Although glibc is often portrayed³ as some kind of Linux kernel wrapper, they are entirely separate projects. Linux manuals⁴ also make it seem like they are one and the same:

> The Linux man-pages project documents the Linux kernel and C library interfaces that are employed by user-space programs.

These same manuals also document systemd as if it was part of Linux. I went there expecting low level documentation useful for writing one's own init system and got systemd documentation instead. It's very confusing in my opinion. Why are external projects documented in the Linux manuals?

Anyway, these kernel features are used by C libraries to implement all their functions. Using C libraries is the traditional way to build a Linux user space but it is certainly not the only way. Compilers could emit these system calls directly, avoiding the need for a runtime library. A programming language virtual machine could be built directly on top of Linux system calls. It is possible to create freestanding programs that run on Linux with zero dependencies.

Incompatibilities are caused by these user space libraries, not by the system calls themselves. For example, glibc maintains a lot of thread local state and will not work correctly if the program calls clone(). A program that does not link to glibc does not have this limitation.

Although low level, Linux system calls are in many ways a simpler interface: their behavior is more precisely documented compared to POSIX; there is no need to deal with errno; there is no hidden C library functionality that's hard to understand; freestanding programs do not contain references to hundreds of hidden standard library symbols that implement obscure functionality.

The kernel itself containd a nolibc.h header[5] that it apparently uses for its own tools.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[3]: https://en.wikipedia.org/wiki/File:Linux_kernel_System_Call_...

[4]: https://www.kernel.org/doc/man-pages/

[5]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

> I don't think this is true, at least on Linux.

My assertion pertains to systems. Linux is not a system.

> Even the commonly used vDSO² is a stable interface.

https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

> [snip completely irrelevant everything else]

> What would be the security concern with allowing syscalls only from preauthorized (ie msyscall(2)) regions

Who preauthorizes them, and what prevents more from getting added?

Currently ls.so upon linking in libc; invoking msyscall() is only permitted once per process.

Seeing as msyscall() is itself a system call, any calls to it must themselves originate from an authorized region.

Correct. So, now, if you want to allow any program, and presumably its libraries, to register their regions of memory as being syscall-worthy you need to lift the called-once restrictions, which opens a hole for an attacker.

I think the idea here is to just let the linker do it.

Which is why go is such a problem -- because the linker can't do it without hacks and guesswork, in the case of a static binary that dlopens libc.

I'm aware of the issues. I was a part of the discussions in the hut when they were being implemented.

> you need to lift the called-once restrictions, which opens a hole for an attacker

I don't see how that's the case; my original question was essentially asking what that security hole is. Provided that syscall ability is opt-out by default and that only code subjected to ASLR is permitted to be authorized, it doesn't seem terribly risky to allow additional such regions to be registered. An exploit has to contend with ASLR either way; either by locating libc, or by locating some other authorized region within the current process.

ASLR isn't a complete solution. It's not that hard to find libc, so this is just another hurdle, not a full barrier. You're proposing weakening the barrier.

I'm not proposing anything, I'm asking for a concrete explanation of the supposed security hole. I agree that ASLR isn't a complete security solution and never implied otherwise.

AFAIU, the entire security benefit here is due to ASLR alone. If an exploit manages to track down libc, it can go right ahead and make all the system calls it wants. (Unless there's some other piece to the puzzle that I've missed? Is there something special about libc in particular?) As such, I still don't understand how the called-once restriction is supposed to meaningfully increase security - by the time you've found the msyscall() function, you've also found _all the others_ anyway.

> AFAIU, the entire security benefit here is due to ASLR alone. If an exploit manages to track down libc, it can go right ahead and make all the system calls it wants

It has to create the appropriate gadgets to generate function call sequences, and generating gadgets is hard.

Reply on news.ycombinator.com