5 ms·

It's an important comparison of the mechanisms, even in 2023, you can still find binaries on modern Linux distributions with executable stacks due to the fail-o

by brynet 3y ago

It's an important comparison of the mechanisms, even in 2023, you can still find binaries on modern Linux distributions with executable stacks due to the fail-open design, 20 years later. The fact that Linux hasn't learned the right lessons in 20 years, and has chosen to "double down" in respect to IBT/BTI, does not inspire confidence that they will ever fix it. I'd say his 20 year estimate was in fact being pretty generous given the evidence available. https://news.ycombinator.com/item?id=21554975 https://news.ycombinator.com/item?id=21554975

whoopdedo 3y ago
It's the price you pay for never-break-userspace. OpenBSD is fine with the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules. The answer to that is to recompile because you've still got the source, and if not, well, tough cookies.
- loeg 3y ago
  > OpenBSD is fine with the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules. To clarify slightly, OpenBSD is fine with the very high probability that an executable will fail under new rules. Otherwise, yes.
- ndesaulniers 3y ago
  > the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules Isn't it any indirect branch in any program that will trip BTI/IBT? So most programs? I guess I disagree with the `small probability ` part.
- jacquesm 3y ago
  Tough cookies translates for many people into: OpenBSD is not for me. The 'very small probability' likely approaches '1' for sufficiently old enough stuff. And even if you do have the source, does it still build without substantial work? Backwards compatibility is not something to toss out the window without thinking through the consequences.
mananaysiempre 3y ago
> It's an important comparison of the mechanisms, even in 2023, you can still find binaries on modern Linux distributions with executable stacks due to the fail-open design, 20 years later. Unfortunately, for C code using GCC’s nested functions extension (or for languages that want to be ABI-compatible with C and support nested functions, like that paragon of advanced features called Pascal /s ), there’s no other compilation strategy in current ABIs. The patches to switch C (and not just Ada) to function descriptors[1] with an ABI break have been sitting on the GCC mailing list since approximately forever[2], but it doesn’t seem like there’s been any progress. [1] The strategy is basically to compile (*fp)() not as call *%rax but as (untested) test $1, %rax jz 1f mov 8(%rax), %r10 mov (%rax), %rax 1: call *%rax thus essentially inlining the (currently stack-allocated) closure calling thunk at all indirect call sites. It is ABI-compatible on x86 and x86-64 with all code that does not involve nested functions, place functions at odd addresses, or tag function pointers itself (and I think with all arm64 and riscv code, although arm32’s usage of the low pointer bit for Thumb interworking is bound to make this trickier). [2] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-01/msg00735.html https://gcc.gnu.org/legacy-ml/gcc-patches/2019-01/msg00735.h...
- brynet 3y ago
  That strategy won't fly with IBT. Now all software must pay the price and miss out on important mitigations, for all eternity, just because of some largely unused feature in one compiler?
  - mananaysiempre 3y ago
    IBT is already further along here. The hypothetical solution for executable stacks is to recompile all of your nested-function-using or -calling code with -ftrampolines (except that won’t work without the patch above—silently, really GCC?..). The already real and working solution for IBT is to recompile all of your indirect-branch-using code with -fcf-protection=branch. So, ignoring the fact that nested functions are in practice much rarer, if you accept the former as valid you’ll need to accept the latter as well, as far as logic as concerned. I wouldn’t characterize this as a “largely unused feature in one compiler” screwing things up, but rather as the ABI on most Linux and -adjacent platforms (except SysV Itanium and FDPIC IIRC) being incapable of supporting closures (without executable stacks). That these are missing from standard C, and only present in languages that are either niche (Pascal, Ada) or don’t care about following the platform ABI (Rust, Go, C++’s lambdas), is a defect of C (and that’s at least a somewhat popular opinion among ISO C committee members[1]). Of course, OpenBSD essentially does not have a stable ABI, so it’s much freer to experiment here. [1] https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my https://thephd.dev/lambdas-nested-functions-block-expression...
jacquesm 3y ago
The funny thing is that this attitude towards breaking changes is one of the reasons why Theo is able to make this comment at all. If he would allow breaking changes then OpenBSD adoption likely would be higher and that in turn would cause him to resist the kind of things that Linux would not be able to get away with. It's clearly different philosophies leading to different outcomes with neither of them clearly better than the other, it just depends on what you need. It would be possible to make that statement in a more graceful way.
- binkHN 3y ago
  Theo himself considers OpenBSD a “research” OS, so I don’t think he’ll ever consider OpenBSD going mainstream, especially as it allows stuff like this to happen.
  - jacquesm 3y ago
    Indeed, so it's apples-to-oranges.
- sillywalk 3y ago
  "I have altered the ABI. Pray I do not alter it further." -- Theo de Raadt https://marc.info/?l=openbsd-tech&m=157489277318829&w=2 https://marc.info/?l=openbsd-tech&m=157489277318829&w=2

by brynet 3y ago

whoopdedo 3y ago

It's the price you pay for never-break-userspace. OpenBSD is fine with the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules. The answer to that is to recompile because you've still got the source, and if not, well, tough cookies.

loeg 3y ago
> OpenBSD is fine with the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules. To clarify slightly, OpenBSD is fine with the very high probability that an executable will fail under new rules. Otherwise, yes.
ndesaulniers 3y ago
> the very small probability that an executable which doesn't do branch tracking will fail to run under the enforced rules Isn't it any indirect branch in any program that will trip BTI/IBT? So most programs? I guess I disagree with the `small probability ` part.
jacquesm 3y ago
Tough cookies translates for many people into: OpenBSD is not for me. The 'very small probability' likely approaches '1' for sufficiently old enough stuff. And even if you do have the source, does it still build without substantial work? Backwards compatibility is not something to toss out the window without thinking through the consequences.

mananaysiempre 3y ago

> It's an important comparison of the mechanisms, even in 2023, you can still find binaries on modern Linux distributions with executable stacks due to the fail-open design, 20 years later. Unfortunately, for C code using GCC’s nested functions extension (or for languages that want to be ABI-compatible with C and support nested functions, like that paragon of advanced features called Pascal /s ), there’s no other compilation strategy in current ABIs. The patches to switch C (and not just Ada) to function descriptors[1] with an ABI break have been sitting on the GCC mailing list since approximately forever[2], but it doesn’t seem like there’s been any progress. [1] The strategy is basically to compile (*fp)() not as call *%rax but as (untested) test $1, %rax jz 1f mov 8(%rax), %r10 mov (%rax), %rax 1: call *%rax thus essentially inlining the (currently stack-allocated) closure calling thunk at all indirect call sites. It is ABI-compatible on x86 and x86-64 with all code that does not involve nested functions, place functions at odd addresses, or tag function pointers itself (and I think with all arm64 and riscv code, although arm32’s usage of the low pointer bit for Thumb interworking is bound to make this trickier). [2] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-01/msg00735.html https://gcc.gnu.org/legacy-ml/gcc-patches/2019-01/msg00735.h...

brynet 3y ago
That strategy won't fly with IBT. Now all software must pay the price and miss out on important mitigations, for all eternity, just because of some largely unused feature in one compiler?
- mananaysiempre 3y ago
  IBT is already further along here. The hypothetical solution for executable stacks is to recompile all of your nested-function-using or -calling code with -ftrampolines (except that won’t work without the patch above—silently, really GCC?..). The already real and working solution for IBT is to recompile all of your indirect-branch-using code with -fcf-protection=branch. So, ignoring the fact that nested functions are in practice much rarer, if you accept the former as valid you’ll need to accept the latter as well, as far as logic as concerned. I wouldn’t characterize this as a “largely unused feature in one compiler” screwing things up, but rather as the ABI on most Linux and -adjacent platforms (except SysV Itanium and FDPIC IIRC) being incapable of supporting closures (without executable stacks). That these are missing from standard C, and only present in languages that are either niche (Pascal, Ada) or don’t care about following the platform ABI (Rust, Go, C++’s lambdas), is a defect of C (and that’s at least a somewhat popular opinion among ISO C committee members[1]). Of course, OpenBSD essentially does not have a stable ABI, so it’s much freer to experiment here. [1] https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my https://thephd.dev/lambdas-nested-functions-block-expression...

jacquesm 3y ago

The funny thing is that this attitude towards breaking changes is one of the reasons why Theo is able to make this comment at all. If he would allow breaking changes then OpenBSD adoption likely would be higher and that in turn would cause him to resist the kind of things that Linux would not be able to get away with. It's clearly different philosophies leading to different outcomes with neither of them clearly better than the other, it just depends on what you need. It would be possible to make that statement in a more graceful way.

binkHN 3y ago
Theo himself considers OpenBSD a “research” OS, so I don’t think he’ll ever consider OpenBSD going mainstream, especially as it allows stuff like this to happen.
- jacquesm 3y ago
  Indeed, so it's apples-to-oranges.
sillywalk 3y ago
"I have altered the ABI. Pray I do not alter it further." -- Theo de Raadt https://marc.info/?l=openbsd-tech&m=157489277318829&w=2 https://marc.info/?l=openbsd-tech&m=157489277318829&w=2