4 ms·

Okay. How do you tell the kernel that? Sure, the kernel will have put a guard page or more at the end of the stack, so that if you regularly push onto the stack

by anyfoo 4y ago

Okay. How do you tell the kernel that? Sure, the kernel will have put a guard page or more at the end of the stack, so that if you regularly push onto the stack, you will eventually hit a guard page and things will blow up appropriately. But what if the length of your variable length array is, say, gigabytes, you've blown way past the guard pages, and your pointer is now in non-stack kernel land. You'd have to check the stack pointer all the time to be sure, that's prohibitive performance-wise. Ironically, x86 kind of had that in hardware back when segmentation was still used.

Dylan16807 4y ago
I think the normal pattern is a stack probe every page or so when there's a sufficiently large allocation. There's no need to check the stack pointer all the time. But that's not my point. If the compiler/runtime knows it will blow up if you have an allocation over 4KB or so, then it needs to do something to mitigate or reject allocations like that.
- anyfoo 4y ago
  > I think the normal pattern is a stack probe every page or so when there's a sufficiently large allocation. What exactly are you doing there, in kernel code? > But that's not my point. If the compiler/runtime knows it will blow up if you have an allocation over 4KB or so, then it needs to do something to mitigate or reject allocations like that. Do what exactly? Just reject stack allocations that are larger than the cluster of guard pages? And keep book of past allocations? A lot of that needs to happen at runtime, since the compiler doesn't know the size with VLAs. It's not impossible and mitigations exist, but it is pretty "extra". gcc has -fstack-check that (I think) does something there.
  - Dylan16807 4y ago
    > What exactly are you doing there, in kernel code? In kernel code? What you're doing is triggering the guard page over and over if the stack is pushing into new territory. > Do what exactly? Just reject stack allocations that are larger than the cluster of guard pages? And keep book of past allocations? A lot of that needs to happen at runtime, since the compiler doesn't know the size with VLAs. Just hit the guard pages. You don't need to know the stack size or have any bookkeeping to do that, you just prod a byte every page_size. And you only need to do that for allocations that are very big. In normal code it's just a single not-taken branch for each VLA.
    - anyfoo 4y ago
      That seems to be what -fstack-check for gcc is doing: "If neither of the above are true, GCC will generate code to periodically “probe” the stack pointer using the values of the macros defined below."[1] I guess I'm wondering why this isn't always on if it solves the problem with negligible cost? Genuine question, not trying to make a point. [1] https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html
      - Dylan16807 4y ago
        What I'm finding in a quick search is: * It should be fast, but I haven't found a benchmark. * There appear to be some issues of signals hitting at the wrong time vs. angering valgrind, depending on probe timing. * Probes like this are mandatory on windows to make sure the stack is allocated, so it can't be that bad.
        anyfoo 4y ago
        I'm mostly interested in it for kernel code though, so the second point at least does not apply, at least not directly. Maybe there is something analogous when preempting kernel threads, I haven't thought it through at all. But interesting.
      - Joker_vD 4y ago
        Because it's on by default in MSVC [0], and we all know that whatever technical decisions MS makes, they're superior to whatever technical decision the GNU people make. /s Speaking seriously, I too would like an answer. [0] https://docs.microsoft.com/en-us/windows/win32/devnotes/-win32-chkstk https://docs.microsoft.com/en-us/windows/win32/devnotes/-win...
        pjmlp 4y ago
        One decision Microsoft made was not to support VLAs at all, even after their new found C love.
    - 4y ago

by anyfoo 4y ago

Dylan16807 4y ago

I think the normal pattern is a stack probe every page or so when there's a sufficiently large allocation. There's no need to check the stack pointer all the time. But that's not my point. If the compiler/runtime knows it will blow up if you have an allocation over 4KB or so, then it needs to do something to mitigate or reject allocations like that.

anyfoo 4y ago
> I think the normal pattern is a stack probe every page or so when there's a sufficiently large allocation. What exactly are you doing there, in kernel code? > But that's not my point. If the compiler/runtime knows it will blow up if you have an allocation over 4KB or so, then it needs to do something to mitigate or reject allocations like that. Do what exactly? Just reject stack allocations that are larger than the cluster of guard pages? And keep book of past allocations? A lot of that needs to happen at runtime, since the compiler doesn't know the size with VLAs. It's not impossible and mitigations exist, but it is pretty "extra". gcc has -fstack-check that (I think) does something there.
- Dylan16807 4y ago
  > What exactly are you doing there, in kernel code? In kernel code? What you're doing is triggering the guard page over and over if the stack is pushing into new territory. > Do what exactly? Just reject stack allocations that are larger than the cluster of guard pages? And keep book of past allocations? A lot of that needs to happen at runtime, since the compiler doesn't know the size with VLAs. Just hit the guard pages. You don't need to know the stack size or have any bookkeeping to do that, you just prod a byte every page_size. And you only need to do that for allocations that are very big. In normal code it's just a single not-taken branch for each VLA.
  - anyfoo 4y ago
    That seems to be what -fstack-check for gcc is doing: "If neither of the above are true, GCC will generate code to periodically “probe” the stack pointer using the values of the macros defined below."[1] I guess I'm wondering why this isn't always on if it solves the problem with negligible cost? Genuine question, not trying to make a point. [1] https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html
    - Dylan16807 4y ago
      What I'm finding in a quick search is: * It should be fast, but I haven't found a benchmark. * There appear to be some issues of signals hitting at the wrong time vs. angering valgrind, depending on probe timing. * Probes like this are mandatory on windows to make sure the stack is allocated, so it can't be that bad.
      - anyfoo 4y ago
        I'm mostly interested in it for kernel code though, so the second point at least does not apply, at least not directly. Maybe there is something analogous when preempting kernel threads, I haven't thought it through at all. But interesting.
    - Joker_vD 4y ago
      Because it's on by default in MSVC [0], and we all know that whatever technical decisions MS makes, they're superior to whatever technical decision the GNU people make. /s Speaking seriously, I too would like an answer. [0] https://docs.microsoft.com/en-us/windows/win32/devnotes/-win32-chkstk https://docs.microsoft.com/en-us/windows/win32/devnotes/-win...
      - pjmlp 4y ago
        One decision Microsoft made was not to support VLAs at all, even after their new found C love.
  - 4y ago