4 ms·

~64 KiB of stack ought to be enough for anybody. https://github.com/torvalds/linux/blob/84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d/arch/x86/mm/fault.c#L1359 http

~64 KiB of stack ought to be enough for anybody. https://github.com/torvalds/linux/blob/84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d/arch/x86/mm/fault.c#L1359 https://github.com/torvalds/linux/blob/84df9525b0c27f3ebc2eb...

bibanez 3y ago
The article mentions this was fixed in Kernel 4.20
mike_hock 3y ago
Yes, it ought to be. I can hardly see that as a "bug" in Linux. Clearly, allocating 20k stack variables can't be right and the bug is on Google's side. The stack isn't for bulk storage, I thought that was common knowledge.
- veave 3y ago
  If a javascript program crashes the interpreter that is a bug in the interpreter. I don't understand how this is even a discussion. In the era of IE6 there were lots of one-liners that could crash the browser and no one would blame whoever wrote them.
  - mike_hock 3y ago
    In the interpreter, yes, not the kernel that enforces a reasonable stack limit.
    - realitythreek 3y ago
      It had already been fixed in the kernel. Linus tends to agree with it being a bug.
- AshamedCaptain 3y ago
  Its even worse, since they are not increasing the stack pointer and thus firefox is violating some redzone abi somewhere.
asveikau 3y ago
I seem to recall long ago there was an exploitable bug due to excessive stack use. Basically the way a kernel detects stack growth is via a guard page that causes a fault on memory access. If the allocation is bigger than the offset to the guard page, and the start of the allocation is accessed before the end, you get this. An attacker might even be able to generate a non-faulting memory access pointing at somebody else's buffer. I think it's on the language implementation to understand what that offset might be and generate benign memory access on large stack allocations, allowing the kernel to fault and intervene. Consider it part of the ABI where you're running.
- remram 3y ago
  Or maybe don't allocate 20kB objects on the stack.
- leodag 3y ago
  Wasn't that because of Variable-Length Arrays? I remember a while back there was a movement to remove all of them from the kernel.
  - asveikau 3y ago
    Perhaps. I think there are other reasons to avoid VLAs. I've heard the code generated for them kinda sucks. But IMO a compiler should generate extra benign reads on a large stack allocation. You mention avoiding VLAs in the kernel, but even user mode code has this problem. Certainly a browser JITing random JS from the internet should be able to work around such a problem.

bibanez 3y ago

The article mentions this was fixed in Kernel 4.20

mike_hock 3y ago

Yes, it ought to be. I can hardly see that as a "bug" in Linux. Clearly, allocating 20k stack variables can't be right and the bug is on Google's side. The stack isn't for bulk storage, I thought that was common knowledge.

veave 3y ago
If a javascript program crashes the interpreter that is a bug in the interpreter. I don't understand how this is even a discussion. In the era of IE6 there were lots of one-liners that could crash the browser and no one would blame whoever wrote them.
- mike_hock 3y ago
  In the interpreter, yes, not the kernel that enforces a reasonable stack limit.
  - realitythreek 3y ago
    It had already been fixed in the kernel. Linus tends to agree with it being a bug.
AshamedCaptain 3y ago
Its even worse, since they are not increasing the stack pointer and thus firefox is violating some redzone abi somewhere.

asveikau 3y ago

I seem to recall long ago there was an exploitable bug due to excessive stack use. Basically the way a kernel detects stack growth is via a guard page that causes a fault on memory access. If the allocation is bigger than the offset to the guard page, and the start of the allocation is accessed before the end, you get this. An attacker might even be able to generate a non-faulting memory access pointing at somebody else's buffer. I think it's on the language implementation to understand what that offset might be and generate benign memory access on large stack allocations, allowing the kernel to fault and intervene. Consider it part of the ABI where you're running.

remram 3y ago
Or maybe don't allocate 20kB objects on the stack.
leodag 3y ago
Wasn't that because of Variable-Length Arrays? I remember a while back there was a movement to remove all of them from the kernel.
- asveikau 3y ago
  Perhaps. I think there are other reasons to avoid VLAs. I've heard the code generated for them kinda sucks. But IMO a compiler should generate extra benign reads on a large stack allocation. You mention avoiding VLAs in the kernel, but even user mode code has this problem. Certainly a browser JITing random JS from the internet should be able to work around such a problem.