4 ms·

with_resource(mutex file handle etc etc *o, func callback) is a safer pattern, for this reason. Thank you, Python (with_resource is a generic example. Search f

with_resource(mutex file handle etc etc *o, func callback) is a safer pattern, for this reason. Thank you, Python (with_resource is a generic example. Search for such capabilities in your library.) Computers exist to automate. Let the computer remember to close resources upon scope end. Go's defer is also helpful in this regard.

viraptor 4y ago
That was my first thought - would they leave the set_fs solution in place if C had a native solution for resource blocks / RAII+drop.
- ars 4y ago
  It's not that hard to do in C. Make a macro that takes a function, it runs: set_fs(KERN) *function_pointer() set_fs(USER) There did it before, so they knew about that option, and if they didn't do it, they must have had a reason.
  - simias 4y ago
    It's true, unfortunately the lack of lambdas in C makes this pattern cumbersome. You could achieve it with a macro instead, I suppose.
- shaded-enmity 4y ago
  A simple policy that both set_fs() calls need to happen within the same function body with corresponding CI test based on AST/DWARF inspection would have also prevented it. Do you really want to rely on stack unwinding/destructors for security sensitive code when stack is usually the first thing that gets controlled by the attacker? Exception handling (SEH) on Windows is an exploitation vector of it's own.
  - viraptor 4y ago
    I'm talking about the general idea not specific implementation. Having something happen at function/block exit doesn't mean a runtime configurable behaviour. If you don't have exceptions, it's pretty easy to statically compile that behaviour and guarantee it rather than rely on checks.
    - shaded-enmity 4y ago
      You still need to implement a CI rule so that I don't just call `set_fs()` without using `preferred_syntax(set_fs)`, don't you?
      - viraptor 4y ago
        We're talking a theoretical language here, so... maybe? It could be also that set_fs is usable only in the preferred_syntax mode.
- SolarNet 4y ago
  Except that things are weird in a kernel, one cannot guarantee that language behavior is enforceable. Even with a RAII/drop style solution there is a possibility that kernel weirdness will prevent it from running correctly. The issue with forgetting function calls like this are the edge cases, and the kernel has a lot more of those.
- Matthias247 4y ago
  There is a GCC extension (__attribute__ cleanup) [1] gcc which they probably could use if they wanted, given that the kernel relies primarily on gcc (and clang supports gcc extensions). Probably not allowed through the kernel coding style? [1] https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attribute...
- jcranmer 4y ago
  The problem isn't that it relies on developer foresight to make the second call to set_fs. The problem (if you look through other LWN articles on the subject) is that the set_fs calls can be prone to not getting restored if the kernel code is interrupted.

viraptor 4y ago

That was my first thought - would they leave the set_fs solution in place if C had a native solution for resource blocks / RAII+drop.

ars 4y ago
It's not that hard to do in C. Make a macro that takes a function, it runs: set_fs(KERN) *function_pointer() set_fs(USER) There did it before, so they knew about that option, and if they didn't do it, they must have had a reason.
- simias 4y ago
  It's true, unfortunately the lack of lambdas in C makes this pattern cumbersome. You could achieve it with a macro instead, I suppose.
shaded-enmity 4y ago
A simple policy that both set_fs() calls need to happen within the same function body with corresponding CI test based on AST/DWARF inspection would have also prevented it. Do you really want to rely on stack unwinding/destructors for security sensitive code when stack is usually the first thing that gets controlled by the attacker? Exception handling (SEH) on Windows is an exploitation vector of it's own.
- viraptor 4y ago
  I'm talking about the general idea not specific implementation. Having something happen at function/block exit doesn't mean a runtime configurable behaviour. If you don't have exceptions, it's pretty easy to statically compile that behaviour and guarantee it rather than rely on checks.
  - shaded-enmity 4y ago
    You still need to implement a CI rule so that I don't just call `set_fs()` without using `preferred_syntax(set_fs)`, don't you?
    - viraptor 4y ago
      We're talking a theoretical language here, so... maybe? It could be also that set_fs is usable only in the preferred_syntax mode.
SolarNet 4y ago
Except that things are weird in a kernel, one cannot guarantee that language behavior is enforceable. Even with a RAII/drop style solution there is a possibility that kernel weirdness will prevent it from running correctly. The issue with forgetting function calls like this are the edge cases, and the kernel has a lot more of those.
Matthias247 4y ago
There is a GCC extension (__attribute__ cleanup) [1] gcc which they probably could use if they wanted, given that the kernel relies primarily on gcc (and clang supports gcc extensions). Probably not allowed through the kernel coding style? [1] https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attribute...
jcranmer 4y ago
The problem isn't that it relies on developer foresight to make the second call to set_fs. The problem (if you look through other LWN articles on the subject) is that the set_fs calls can be prone to not getting restored if the kernel code is interrupted.