3 ms·

TFA is right, sadly. One of the projects I was to go in the future is implement boringcc [1], and this sounds like something I would want in it. The question

TFA is right, sadly. One of the projects I was to go in the future is implement boringcc [1], and this sounds like something I would want in it. The question then becomes: would it even be possible to do? [1]: https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8GGp2K1DAAJ https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8...

miloshadzic 5y ago
The spam on that thread is really something.
qsort 5y ago
Wouldn't the majority of it just be, effectively, "all pointers are now fat"? It could disable some (many?) optimizations, but I don't see it as a particularly hard thing to do (at least conceptually).
- ghoward 5y ago
  No, not a hard thing to make a boringcc compiler, but I was referring specifically to querying stack size.
hdjjhhvvhga 5y ago
Probably the only way is to use platform-specific quirks, but that's basically the same with everything else. The portability only works for some generic code, pretty much any non-trivial/real-world software uses a lot of platform-specific code.
cryptonector 5y ago
TFA is wrong. The C run-time's call frame allocation method and actual resource limits leak past the C function call and variable-length-array (VLA) abstractions. You can write portable code to force defined (by the platform, not by the C spec) resource exhaustion behavior sooner than undefined behavior caused by memory corruption caused by use of much-larger-than-the-stack stack allocations.
- ghoward 5y ago
  Can you really? If you depend on a SIGSEGV handler, that handler needs stack space unless you set up a separate stack for it, and I am not sure that is portable.
  - cryptonector 5y ago
    The point is to cause a defined (by the platform) stack exhaustion failure mode before possibly causing undefined behavior by corrupting memory. The C specs do not define any resource exhaustion failure modes. But actual operating systems, ABIs, platforms -- they do. If you are on a system that gives you a SIGSEGV but no way to catch it on an alternate stack -or if you don't catch or ignore it- then your process will crash. This is fine. It's better than memory corruption.
    - ghoward 5y ago
      Can you give me an example of a platform where your program cannot cause memory corruption if you access an array on the stack out of bounds far enough to corrupt actual existing memory on the heap? Because a SIGSEGV is the best case scenario; the other scenarios are not helped at all by platforms.
      - cryptonector 5y ago
        Say you alloca(1GB), and alloca() is naive and gives it to you even though that 1GB spans several other stacks, and now you write somewhere in the middle. If you're lucky you'll hit unmapped space and trigger a segfault. If you're unlucky you'll scribble over another thread's stack or whatever. But if you progressively write into the alloca()ed area in the direction of stack growth then you cannot corrupt other mappings, and you can only segfault if you exceed your stack's maximum size. Of course, there can be platforms with no SIGSEGV or whatever.

miloshadzic 5y ago

The spam on that thread is really something.

qsort 5y ago

Wouldn't the majority of it just be, effectively, "all pointers are now fat"? It could disable some (many?) optimizations, but I don't see it as a particularly hard thing to do (at least conceptually).

ghoward 5y ago
No, not a hard thing to make a boringcc compiler, but I was referring specifically to querying stack size.

hdjjhhvvhga 5y ago

Probably the only way is to use platform-specific quirks, but that's basically the same with everything else. The portability only works for some generic code, pretty much any non-trivial/real-world software uses a lot of platform-specific code.

cryptonector 5y ago

TFA is wrong. The C run-time's call frame allocation method and actual resource limits leak past the C function call and variable-length-array (VLA) abstractions. You can write portable code to force defined (by the platform, not by the C spec) resource exhaustion behavior sooner than undefined behavior caused by memory corruption caused by use of much-larger-than-the-stack stack allocations.

ghoward 5y ago
Can you really? If you depend on a SIGSEGV handler, that handler needs stack space unless you set up a separate stack for it, and I am not sure that is portable.
- cryptonector 5y ago
  The point is to cause a defined (by the platform) stack exhaustion failure mode before possibly causing undefined behavior by corrupting memory. The C specs do not define any resource exhaustion failure modes. But actual operating systems, ABIs, platforms -- they do. If you are on a system that gives you a SIGSEGV but no way to catch it on an alternate stack -or if you don't catch or ignore it- then your process will crash. This is fine. It's better than memory corruption.
  - ghoward 5y ago
    Can you give me an example of a platform where your program cannot cause memory corruption if you access an array on the stack out of bounds far enough to corrupt actual existing memory on the heap? Because a SIGSEGV is the best case scenario; the other scenarios are not helped at all by platforms.
    - cryptonector 5y ago
      Say you alloca(1GB), and alloca() is naive and gives it to you even though that 1GB spans several other stacks, and now you write somewhere in the middle. If you're lucky you'll hit unmapped space and trigger a segfault. If you're unlucky you'll scribble over another thread's stack or whatever. But if you progressively write into the alloca()ed area in the direction of stack growth then you cannot corrupt other mappings, and you can only segfault if you exceed your stack's maximum size. Of course, there can be platforms with no SIGSEGV or whatever.