5 ms·

Indirect Calling of Nested Functions on GCC Without Executable Stack

75 points by uecker 2mo ago

inigyou 2mo ago
Self-modifying code is cool. It's a shame we had to disable it for security.
- mcculley 1mo ago
  Not just security. Instruction caches must also be aware of self-modifying code.
  - inigyou 1mo ago
    yes but it's easy enough to issue a cache flush when you modify the code. The overhead of cache flushing means some old school techniques are no longer viable, like modifying a constant in the next instruction. However it is still interesting to write machine code snippets once and execute them many times, like the nested function trampolines. I had a case where I had RGB masks like R=0x00ff0000 etc (loaded at startup once) and wanted to convert 0x00rrggbb to match the mask (so no-op in the common case but not always) which could have involved setting the shift amounts in a series of shift instructions. The Linux kernel uses self-modification to change branches depending on whether certain features are on. For example when a user-mode process starts tracing a certain function, it adds code to the beginning of that function to trace the call, otherwise it pads that space with a no-op. JIT compilers also make good use of knowing whether a class has any subclasses, which is statically unknowable in Java but dynamically knowable.
    - codedokode 1mo ago
      Modifying a constant in code might make sense because it saves several precious bytes of variable storage.
      - inigyou 1mo ago
        No, it might make sense because it saves precious memory bandwidth as well as uop count. This code wasn't called that often, generally once per drawing operation, but I don't like being uselessly wasteful - that mindset is how software got so bloated. Your program is either front-end stalled by uop count or instruction cache latency, or back-end bound by memory bandwidth or ALU throughput or a serial dependency chain. It doesn't matter which is the bottleneck for this case, because inlining constants improves most of the above!
        inigyou 1mo ago
        s/stalled/bound/ When the back end is the bottleneck, the front end stalls and vice versa, though I'm not sure how all processors report it.
    - comex 1mo ago
      Yep. Even outside of tracing, there are several different ways that the Linux kernel patches itself: - Static calls: like a call to a global function pointer, except instead of loading a function pointer and doing an indirect call, the code is patched to do a direct call to the destination - Static keys: like an if statement testing a global boolean, except instead of loading a boolean and doing a conditional branch, the code is patched to do either an unconditional branch or a nop - Runtime constants: like a load of a global variable, except instead of loading, the value is patched directly into the code - Alternatives: selects one of multiple possible instruction sequences depending on (usually) whether the CPU supports specific instructions It's really fascinating to see the kind of fun efficient stuff you can do when you have that level of low-level control. Not just code patching but things like RCU as well. > However it is still interesting to write machine code snippets once and execute them many times, like the nested function trampolines. I slightly disagree on this though. In my experience writing code with Clang blocks (which don't use trampolines), they're often useful for code organization even if the callback will only be called once. Therefore, even ignoring security issues, I think GCC choosing a design that required cache flushing was a mistake - certainly in retrospect (as cache flushing has become more expensive over the years), but perhaps even at the time. I did some research, and trampolines were introduced in GCC 2.0, which already included mprotect calls and/or cache flushes on some of the architectures it supported, such as MIPS. However, this was a relatively new development, and on most of the supported architectures it didn't do either of those things. But on MIPS it would do an mprotect every single time a trampoline was created, which can't have been fast.
      - inigyou 1mo ago
        It's not the cache flush that's expensive, it's loading the new instructions that aren't cached. If you are flushing the very next instruction and then immediately executing it, that's expensive because of the serial dependency, but if you're generating new code, flushing it shouldn't be more expensive than if you were simply accessing new code for the first time. But on old systems you could modify the very next instruction with no penalty because there wasn't a cache. You can still do that and probably faster than those old systems could (they were slower because of not having a cache, everything was an uncached access), it's just a waste of most of the new system's performance. BTW you can do all of this cool stuff in user mode on Linux too (but not on OpenBSD) - you just have to opt in to executable stack and/or writable .text. I could have written the dynamic shift instruction generator I mentioned, but I didn't want to spend the effort, but I imagined having a language with actual support for something like that (like static keys for variables).
    - jasomill 1mo ago
      The Microsoft Detours[1] library does this for arbitrary Windows API calls. I've used it production to fix simple bugs in third-party software no longer supported by vendors. For example, I have a program that opens Adobe Acrobat Reader as an out-of-process COM server, but tends to leave phantom Acrobat processes hanging around after it quits. To fix this, I wrap CreateProcess in a function that adds any Acrobat processes created to a job object[2] set up to make Windows automatically kill them when the application closes. [1] https://github.com/microsoft/detours https://github.com/microsoft/detours [2] https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects https://learn.microsoft.com/en-us/windows/win32/procthread/j...
  - WalterBright 1mo ago
    Back in the 1980s, text editors had configuration files. The configuration file would be read every time the editor was loaded. This was very slow on a floppy disk system. I realized that, instead of a configuration file, I could configure the executable instead! So, any changes in configuration meant the editor would patch its own exe file! This marvelous technique came to an end when attempts to stop malware got folded into the operating system.
    - weinzierl 1mo ago
      Some early systems, like TeX and I believe some Lisps, took this to the extreme. Instead of patching, they loaded their config once and then dumped the configured process image to a file, which was used in subsequent invocations.
      - compiler-guy 1mo ago
        emacs did this too.
        comex 1mo ago
        And didn't stop doing this until 2020! (Specifically Emacs 27.1, which replaced "unexec", which dumped the process image, with the "portable dumper", which despite the name does not.)
        BillStrong 1mo ago
        And you could still use the unexec method until this very latest release a few days ago, if you didn't want the pdumper.
      - WalterBright 1mo ago
        On a floppy system, it's much faster to just patch it on disk than rewrite it!
      - throwup238 1mo ago
        Pharo [1] is a modern take. [1] https://pharo.org/ https://pharo.org/
- Panzerschrek 1mo ago
  It was maybe cool 50 years ago or so. Nowadays it's no longer needed. Possible performance gains of such code are marginal and modern programming languages allow generating many specialized and optimized code pieces using the same template, so that self-modification is no longer needed. There is also JIT (like in regexp engines), but it's different story.
  - fweimer 1mo ago
    It's still beneficial on some x86-64 implementations to rewrite indirect jumps (as used in PLT stubs) to direct jumps when feasible. For example, AMD says this about the Zen 4 architecture: > Only a limited number of indirect targets that cross a 64MB aligned boundary relative to the branch address can be tracked in the indirect target predictor. Software should limit the number of indirect branch targets that cross such a boundary. And one way doing this is to replace the indirect branch with a direct branch, which supports a 32-bit signed displacement.
    - inigyou 1mo ago
      It's pretty much always beneficial to do something more directly. Doing less work is always better than doing more work. The slowness of modern software is the result of a stack of abstractions acting like a stack of interpreters. You write something in React, that manipulates a React object tree and shadows it to a DOM, which gets shadowed to an internal object tree which gets laid out and shadowed to a stack of GPU layers which gets written out as drawing commands... When you want to scroll up there's so much work to do. To make it fast, cut through layers and minimize work. In the 1990s, scrolling up meant calculating how many pixels to scroll, blitting that many pixels in the main framebuffer (usually GPU accelerated) and then rendering the new pixels at the bottom. There wasn't even a double buffer. Very little abstraction there, just the shortest path to achieve the desired result. The GPU driver did abstract the blit and rendering operations, of course, and the mouse driver abstracted the scrollwheel event, and you may have a wrapper component in your GUI tree that manages a viewport over a larger virtual component, but it's all kept as direct as practical. I can't imagine any electron app using the blit-pixels-up approach. I remember once learning of a runtime environment that would inline class functions. For example they wrote an OS, and if you had an object of a SATA hard drive class, it would copy the function code and inline the drive ID. I don't remember how well it worked for them. A related idea is the "tracing JIT". You know how you expect a JIT to translate one function at a time? A tracing JIT doesn't - it follows the program logic wherever it goes, through whatever control flow, and compiles all of it until it decides to stop. The most well known implementation is probably LuaJIT.
- anitil 1mo ago
  I was re-reading Ian Lance Taylor's series of articles on Linkers [0], and one thing I didn't realise is that using dynamically linked libraries almost requires self-modifying code unless you want to resolve all function calls are start-time (which would make startup slower). I'm still working my way through it so it's possible that I've misunderstood this section, though, and one question I haven't answered is how they get around the typical restriction on w+x pages. [0] Particularly this one https://www.airs.com/blog/archives/41 https://www.airs.com/blog/archives/41
mananaysiempre 2mo ago
Related: previous article in the series, https://news.ycombinator.com/item?id=49308685 https://news.ycombinator.com/item?id=49308685 (103 points, 47 comments)
gue5t 2mo ago
At first, I was annoyed by having to read AT&T syntax. Then I was disoriented by realizing the next snippet was in AT&T syntax without the '%' sigil for registers. But the technique is cool.
- uecker 1mo ago
  Thanks. Sigils fixed (may take a couple of minutes).
Dwedit 1mo ago
What do you need the executable stack for? You call using a function pointer, there's no executable read/write memory involved in using a function pointer.
- tom_ 1mo ago
  Nested functions may require a context pointer of some kind, which the caller can't supply. One way of doing this: create a thunk on the stack that provides the context pointer, and use that address as the pointer to the nested function. But now the stack needs to be executable.
  - ok123456 1mo ago
    Doesn't x86 actually support nested call pointers using enter to natively support this in Pascal?
    - klodolph 1mo ago
      It’s not a question of ISA support. If you call via a function pointer, how do you supply the pointer to the data? (It has to either be in a separate place from the function code, or the same place. One requires an ABI change, the other an executable, writable section of memory.)
      - WalterBright 1mo ago
        > If you call via a function pointer, how do you supply the pointer to the data? D has the notion of a "delegate", which is a (function pointer) and (context pointer) pair. This is incredibly useful, because delegates can: 1. call nested functions that need a pointer to the stack frame of the nestee function 2. call member functions that need `this` pointer 3. call lambdas 4. call COM member functions The neato thing about this is the ABI for delegates is all the same, so a function that gets a delegate parameter will work with any of 1..4. It's one of the most used features of D.
        1mo ago
BobbyTables2 1mo ago
Have always wondered, why can’t nested functions just be normal functions inside a namespace? It seems silly to expose a tiny helper to the entire compilation unit when it is only meant to be used inside one function…
- wavemode 1mo ago
  > why can’t nested functions just be normal functions inside a namespace Because GCC's nested functions are closures - they can access local variables within the function.

75 points by uecker 2mo ago

inigyou 2mo ago

Self-modifying code is cool. It's a shame we had to disable it for security.

mcculley 1mo ago
Not just security. Instruction caches must also be aware of self-modifying code.
- inigyou 1mo ago
  yes but it's easy enough to issue a cache flush when you modify the code. The overhead of cache flushing means some old school techniques are no longer viable, like modifying a constant in the next instruction. However it is still interesting to write machine code snippets once and execute them many times, like the nested function trampolines. I had a case where I had RGB masks like R=0x00ff0000 etc (loaded at startup once) and wanted to convert 0x00rrggbb to match the mask (so no-op in the common case but not always) which could have involved setting the shift amounts in a series of shift instructions. The Linux kernel uses self-modification to change branches depending on whether certain features are on. For example when a user-mode process starts tracing a certain function, it adds code to the beginning of that function to trace the call, otherwise it pads that space with a no-op. JIT compilers also make good use of knowing whether a class has any subclasses, which is statically unknowable in Java but dynamically knowable.
  - codedokode 1mo ago
    Modifying a constant in code might make sense because it saves several precious bytes of variable storage.
    - inigyou 1mo ago
      No, it might make sense because it saves precious memory bandwidth as well as uop count. This code wasn't called that often, generally once per drawing operation, but I don't like being uselessly wasteful - that mindset is how software got so bloated. Your program is either front-end stalled by uop count or instruction cache latency, or back-end bound by memory bandwidth or ALU throughput or a serial dependency chain. It doesn't matter which is the bottleneck for this case, because inlining constants improves most of the above!
      - inigyou 1mo ago
        s/stalled/bound/ When the back end is the bottleneck, the front end stalls and vice versa, though I'm not sure how all processors report it.
  - comex 1mo ago
    Yep. Even outside of tracing, there are several different ways that the Linux kernel patches itself: - Static calls: like a call to a global function pointer, except instead of loading a function pointer and doing an indirect call, the code is patched to do a direct call to the destination - Static keys: like an if statement testing a global boolean, except instead of loading a boolean and doing a conditional branch, the code is patched to do either an unconditional branch or a nop - Runtime constants: like a load of a global variable, except instead of loading, the value is patched directly into the code - Alternatives: selects one of multiple possible instruction sequences depending on (usually) whether the CPU supports specific instructions It's really fascinating to see the kind of fun efficient stuff you can do when you have that level of low-level control. Not just code patching but things like RCU as well. > However it is still interesting to write machine code snippets once and execute them many times, like the nested function trampolines. I slightly disagree on this though. In my experience writing code with Clang blocks (which don't use trampolines), they're often useful for code organization even if the callback will only be called once. Therefore, even ignoring security issues, I think GCC choosing a design that required cache flushing was a mistake - certainly in retrospect (as cache flushing has become more expensive over the years), but perhaps even at the time. I did some research, and trampolines were introduced in GCC 2.0, which already included mprotect calls and/or cache flushes on some of the architectures it supported, such as MIPS. However, this was a relatively new development, and on most of the supported architectures it didn't do either of those things. But on MIPS it would do an mprotect every single time a trampoline was created, which can't have been fast.
    - inigyou 1mo ago
      It's not the cache flush that's expensive, it's loading the new instructions that aren't cached. If you are flushing the very next instruction and then immediately executing it, that's expensive because of the serial dependency, but if you're generating new code, flushing it shouldn't be more expensive than if you were simply accessing new code for the first time. But on old systems you could modify the very next instruction with no penalty because there wasn't a cache. You can still do that and probably faster than those old systems could (they were slower because of not having a cache, everything was an uncached access), it's just a waste of most of the new system's performance. BTW you can do all of this cool stuff in user mode on Linux too (but not on OpenBSD) - you just have to opt in to executable stack and/or writable .text. I could have written the dynamic shift instruction generator I mentioned, but I didn't want to spend the effort, but I imagined having a language with actual support for something like that (like static keys for variables).
  - jasomill 1mo ago
    The Microsoft Detours[1] library does this for arbitrary Windows API calls. I've used it production to fix simple bugs in third-party software no longer supported by vendors. For example, I have a program that opens Adobe Acrobat Reader as an out-of-process COM server, but tends to leave phantom Acrobat processes hanging around after it quits. To fix this, I wrap CreateProcess in a function that adds any Acrobat processes created to a job object[2] set up to make Windows automatically kill them when the application closes. [1] https://github.com/microsoft/detours https://github.com/microsoft/detours [2] https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects https://learn.microsoft.com/en-us/windows/win32/procthread/j...
- WalterBright 1mo ago
  Back in the 1980s, text editors had configuration files. The configuration file would be read every time the editor was loaded. This was very slow on a floppy disk system. I realized that, instead of a configuration file, I could configure the executable instead! So, any changes in configuration meant the editor would patch its own exe file! This marvelous technique came to an end when attempts to stop malware got folded into the operating system.
  - weinzierl 1mo ago
    Some early systems, like TeX and I believe some Lisps, took this to the extreme. Instead of patching, they loaded their config once and then dumped the configured process image to a file, which was used in subsequent invocations.
    - compiler-guy 1mo ago
      emacs did this too.
      - comex 1mo ago
        And didn't stop doing this until 2020! (Specifically Emacs 27.1, which replaced "unexec", which dumped the process image, with the "portable dumper", which despite the name does not.)
        BillStrong 1mo ago
        And you could still use the unexec method until this very latest release a few days ago, if you didn't want the pdumper.
    - WalterBright 1mo ago
      On a floppy system, it's much faster to just patch it on disk than rewrite it!
    - throwup238 1mo ago
      Pharo [1] is a modern take. [1] https://pharo.org/ https://pharo.org/
Panzerschrek 1mo ago
It was maybe cool 50 years ago or so. Nowadays it's no longer needed. Possible performance gains of such code are marginal and modern programming languages allow generating many specialized and optimized code pieces using the same template, so that self-modification is no longer needed. There is also JIT (like in regexp engines), but it's different story.
- fweimer 1mo ago
  It's still beneficial on some x86-64 implementations to rewrite indirect jumps (as used in PLT stubs) to direct jumps when feasible. For example, AMD says this about the Zen 4 architecture: > Only a limited number of indirect targets that cross a 64MB aligned boundary relative to the branch address can be tracked in the indirect target predictor. Software should limit the number of indirect branch targets that cross such a boundary. And one way doing this is to replace the indirect branch with a direct branch, which supports a 32-bit signed displacement.
  - inigyou 1mo ago
    It's pretty much always beneficial to do something more directly. Doing less work is always better than doing more work. The slowness of modern software is the result of a stack of abstractions acting like a stack of interpreters. You write something in React, that manipulates a React object tree and shadows it to a DOM, which gets shadowed to an internal object tree which gets laid out and shadowed to a stack of GPU layers which gets written out as drawing commands... When you want to scroll up there's so much work to do. To make it fast, cut through layers and minimize work. In the 1990s, scrolling up meant calculating how many pixels to scroll, blitting that many pixels in the main framebuffer (usually GPU accelerated) and then rendering the new pixels at the bottom. There wasn't even a double buffer. Very little abstraction there, just the shortest path to achieve the desired result. The GPU driver did abstract the blit and rendering operations, of course, and the mouse driver abstracted the scrollwheel event, and you may have a wrapper component in your GUI tree that manages a viewport over a larger virtual component, but it's all kept as direct as practical. I can't imagine any electron app using the blit-pixels-up approach. I remember once learning of a runtime environment that would inline class functions. For example they wrote an OS, and if you had an object of a SATA hard drive class, it would copy the function code and inline the drive ID. I don't remember how well it worked for them. A related idea is the "tracing JIT". You know how you expect a JIT to translate one function at a time? A tracing JIT doesn't - it follows the program logic wherever it goes, through whatever control flow, and compiles all of it until it decides to stop. The most well known implementation is probably LuaJIT.
anitil 1mo ago
I was re-reading Ian Lance Taylor's series of articles on Linkers [0], and one thing I didn't realise is that using dynamically linked libraries almost requires self-modifying code unless you want to resolve all function calls are start-time (which would make startup slower). I'm still working my way through it so it's possible that I've misunderstood this section, though, and one question I haven't answered is how they get around the typical restriction on w+x pages. [0] Particularly this one https://www.airs.com/blog/archives/41 https://www.airs.com/blog/archives/41

mananaysiempre 2mo ago

Related: previous article in the series, https://news.ycombinator.com/item?id=49308685 https://news.ycombinator.com/item?id=49308685 (103 points, 47 comments)

gue5t 2mo ago

At first, I was annoyed by having to read AT&T syntax. Then I was disoriented by realizing the next snippet was in AT&T syntax without the '%' sigil for registers. But the technique is cool.

uecker 1mo ago
Thanks. Sigils fixed (may take a couple of minutes).

Dwedit 1mo ago

What do you need the executable stack for? You call using a function pointer, there's no executable read/write memory involved in using a function pointer.

tom_ 1mo ago
Nested functions may require a context pointer of some kind, which the caller can't supply. One way of doing this: create a thunk on the stack that provides the context pointer, and use that address as the pointer to the nested function. But now the stack needs to be executable.
- ok123456 1mo ago
  Doesn't x86 actually support nested call pointers using enter to natively support this in Pascal?
  - klodolph 1mo ago
    It’s not a question of ISA support. If you call via a function pointer, how do you supply the pointer to the data? (It has to either be in a separate place from the function code, or the same place. One requires an ABI change, the other an executable, writable section of memory.)
    - WalterBright 1mo ago
      > If you call via a function pointer, how do you supply the pointer to the data? D has the notion of a "delegate", which is a (function pointer) and (context pointer) pair. This is incredibly useful, because delegates can: 1. call nested functions that need a pointer to the stack frame of the nestee function 2. call member functions that need `this` pointer 3. call lambdas 4. call COM member functions The neato thing about this is the ABI for delegates is all the same, so a function that gets a delegate parameter will work with any of 1..4. It's one of the most used features of D.
      - 1mo ago

BobbyTables2 1mo ago

Have always wondered, why can’t nested functions just be normal functions inside a namespace? It seems silly to expose a tiny helper to the entire compilation unit when it is only meant to be used inside one function…

wavemode 1mo ago
> why can’t nested functions just be normal functions inside a namespace Because GCC's nested functions are closures - they can access local variables within the function.