4 ms·
You ask for an automatic allocation of N bytes. You can use alloca() if you have that available, or VLAs if you have that available. If you have neither, then
by cryptonector 5y ago
You ask for an automatic allocation of N bytes. You can use alloca() if you have that available, or VLAs if you have that available.
If you have neither, then you still have to worry that fixed sized automatic allocations might be too large, but at least this can be checked statically.
Given either alloca() or VLAs, those can be allocated on a stack or on a heap, and the spec does not say either way. The OS might over-commit memory, too, and if the C run-time has fixed-sized stacks there may or may not be a guard page at the end.
However, even with all of that, using memcpy() or similar (see elsewhere in this thread) to touch every byte or every 4KB's worth of bytes in what might be the direction of stack growth (if there's a stack, otherwise the direction is irrelevant), is something you can do to make sure that the memory allocated is committed, and that any failure due to over-committing (bounded stacks look like over-committed unbounded stacks) is detected as early as possible and without corrupting memory (e.g., by wildly exceeding stack bounds). Failure may ensue, but it should be behavior defined by the machine rather than undefined behavior.
- alcover 5y ago> fixed sized automatic allocations [...] can be checked statically May I ask how you'd do this ? I need this for optimizing a C project.
- cryptonector 5y agoCheck every function's automatic variables' sizes, add them all up, and add whatever function call frame size the compiler and ABI are using. Getting an exact accounting of function call stack memory usage is tricky because you might have framepointer-less code, and you might have inlining of function calls, but you can figure it out assuming no inlining and assuming you don't enable framepointer-less-ness.
- alcover 5y agoThank you. It doesn't err.. look super straightforward. I was hoping for an automated way of some sort. This stack affair of `local arrays are super fast! but keep it small, 1024 should be okay` is very puzzling to aspiring C lovers like me.
- cryptonector 5y agoThere's a way to dump DWARF debug information that you might then be able to parse and use to do just this.
- jart 5y agoYou can guarantee undetected stack overflow is impossible if you do two things. First you mprotect() a 4096 byte at the bottom of the stack. Second, you program the compiler to fail if an individual function allocates a stack frame larger than that. #ifndef STACK_FRAME_UNLIMITED #pragma GCC diagnostic error "-Wframe-larger-than=4096" #if __GNUC__ >= 9 #pragma GCC diagnostic error "-Walloca-larger-than=1024" #pragma GCC diagnostic error "-Wvla-larger-than=1024" #endif /* GCC 9+ */ #endif /* STACK_FRAME_UNLIMITED */
- alcover 5y agoOh! Now that's an actionable tip. I fail to see the relation between your first measure (which seems to act as a guard?) and the second. Also their sizes don't match. Though I'm afraid I'll encumber this thread with my naive questions.
- nwmcsween 5y agoWhy not mprotect + -fstack-clash-protection?