[HN Gopher] OpenBSD System-Call Pinning
___________________________________________________________________
OpenBSD System-Call Pinning
Author : rwmj
Score : 59 points
Date : 2024-02-02 20:33 UTC (2 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| tptacek wrote:
| System call pinning has been a classic example of an OpenBSD
| approach to exploit mitigation that exploit developers dunk on; a
| thread just a couple months ago:
|
| https://news.ycombinator.com/item?id=38579913
|
| I think? this is the same work, just now merged into the kernel?
| steveklabnik wrote:
| There is a paragraph in the article dedicated to this, starting
| with:
|
| > Security researchers have expressed doubt about how useful
| this check is at preventing compromises.
|
| Doesn't cite the HN thread, but two other cases.
|
| > I think? this is the same work, just now merged into the
| kernel?
|
| That is my understanding, yes. From the article:
|
| > In December, De Raadt sent a patch to the OpenBSD mailing
| list expanding OpenBSD's restrictions on the locations from
| which a process can make system calls. ... Now that patch has
| been merged, finishing a process which De Raadt said has taken
| five years.
| PrimeMcFly wrote:
| > a classic example of an OpenBSD approach to exploit
| mitigation that exploit developers dunk on
|
| Part of why it is hard to take its reputation as as security
| focused OS seriously.
| irdc wrote:
| In their defence, the OpenBSD developers do put their
| mon^H^H^Htime where their mouth is and release their work
| even with dubious features included. How much those features
| _actually_ matter, instead of how much expert opinion says
| they matter, can then be judged in the wild.
|
| Failed experiments are also a good part of research.
| o11c wrote:
| From comments:
|
| > avoiding [...] errno
|
| Note that errno _can_ be optimized by a sufficiently smart
| compiler, simply by treating it as a register, then annotating
| various functions with whether it is preserved, clobbered, or
| conditionally used for return.
|
| The libc boundary is quite annoying though; for this case in
| particular, that it doesn't expose the fact that errno is at a
| fixed offset from the TLS register. And generally, libc is
| vehemently opposed to the existence of smart compilers, since all
| libc calls are expected to be treated as opaque barriers.
| gpderetta wrote:
| well, yes, but you need whole-program compilation.
| yobert wrote:
| > The direct-syscalls-inside-the-binary model used by go (and
| only go, noone else in the history of the unix software does
| this) provided the biggest resistance against this effort".
|
| I know this annoys unix people. But I have to say I actually
| really like that Go shakes this up. I believe the C function
| monopoly just isn't healthy for things. You should be able to
| make a new completely unrelated language. The Go developers were
| the first in a long time to do this, not because they are stupid,
| but because they were ambitious.
| steveklabnik wrote:
| My hot take here is that this split exists because of the way
| that Linux development works differently than other Unices and
| other operating systems. Essentially, it's an example of
| Conway's Law.
|
| As always, things are about API boundaries: what is internal to
| you, and what is exposed externally to your users.
|
| With Linux, well, we all know the rms copypasta: "I'd just like
| to interject for a moment. What you're referring to as Linux,
| is in fact, GNU/Linux, or as I've recently taken to calling it,
| GNU plus Linux." This is a joke, but it also points to
| something real and serious: Linux, being just a kernel, means
| that they provide a stable kernel API. glibc, being written by
| a different organization, builds on top of that API and adds
| its own stable API.
|
| By contrast, many other operating systems are developed as a
| full operating system. They don't produce a kernel as a
| standalone component. As such, they choose some other sort of
| boundary as the API for the OS. On unices, that's often the
| libc. On Windows, that's the Windows API, of which win32 is an
| example.
|
| There are good reasons to not make the kernel your API
| boundary. Different systems make different choices, and that's
| a good thing, not a bad thing.
| anonacct37 wrote:
| I do like this about go. And on Linux it arguably makes sense
| (I say arguable because DNS without CGO is still a common cause
| of issues and incompatibility).
|
| But Linux has, to the best of my understanding said "yes, we
| are ok with users using syscalls". Linux doesn't think that
| glibc is the only project allowed to interface with the kernel.
|
| But for other platforms like OpenBSD and windows they are quite
| simply relying on implementation details that the vendors
| consider to be a private and unsupported interface.
|
| This whole thing is also separate from "is making libc the only
| caller of the syscalls instruction" a good and meaningful
| security improvement.
| cryptonector wrote:
| This isn't about Go vs C. This is about about indirection of
| system calls through stubs and also in a way about static
| linking vs. dynamic linking. Something like this could be done
| for C and others, but the kernel would have to walk the C stack
| to ensure that a) the callers of the system calls are run-time
| library stubs listed in the ELF, and b) that the callers of the
| _stubs_ are listed in the ELFs (plural). Clearly this is easier
| to do if there 's neither stubs nor dynamic linking, but that's
| not a reason to think Go is somehow superior to the rest.
| philsnow wrote:
| > Both [msyscall and pinsyscall] can only be invoked once by a
| given process, which is done by the dynamic linker.
|
| How are/were static executables handled? I'm a little fuzzy on
| how execve notices that a given executable is dynamic (and needs
| ld.so to run it) or static (in which case.. it just jumps to the
| _start symbol?). If the dynamic linker isn't involved, what calls
| msyscall/pinsyscall?
| philsnow wrote:
| Ah, found a good discussion of how it works in Linux
| https://eli.thegreenplace.net/2012/08/13/how-statically-link...
|
| Is it materially different in openbsd?
| brynet wrote:
| Library relinking, mimmutable(2), xonly, along with other recent
| developments such as the removal of indirect syscall(2), make
| syscall pinning all the more interesting, and raise the bar
| against attackers significantly.
|
| One can only hope that more will eventually find its way into
| Linux, like with how paid employees at Google have been spending
| the past ~6 months cloning mimmutable (which HN characters
| decried as "useless") to make mseal() for defending Chrome.
|
| https://marc.info/?l=linux-kernel&w=2&r=1&s=mseal&q=b
| tiffanyh wrote:
| Doesn't macOS do something like this.
___________________________________________________________________
(page generated 2024-02-02 23:00 UTC)