4 ms·
As an example of this, Zoxc has been trying to get stack probe support into LLVM for two years to no avail [0]. This is important to make sure that stack overfl
by mastax 10y ago
As an example of this, Zoxc has been trying to get stack probe support into LLVM for two years to no avail [0]. This is important to make sure that stack overflow or buffer overrun actually trigger the guard page and cause termination.
I admit it's not really fair to LLVM to pick on one patch like this but it's frustrating to me even as an outsider.
[0]: https://reviews.llvm.org/p/Zoxc/ https://reviews.llvm.org/p/Zoxc/
- wyldfire 10y agoIs that just a stack canary? Hasn't gcc had this for years?
- pcwalton 10y agoNo, stack canaries are different. Stack canaries defend against some classes of buffer overflows. Stack probes defend against some classes of stack overflows.
- whitequark_ 10y agoZoxc has repeatedly refused reasonable requests to alter the patch to fit the standards of upstream. Because of this (and because I am rather tired of not having stack probes, with my embedded system not having functional guard pages), I'll make a hostile fork of their patch soon and get it through the pipeline. Stay tuned.
- mastax 10y agoAh, interesting. I hadn't gleamed that from the threads. It's great to hear that there's a chance that this will be supported though!
- dbaupp 10y agoLate comment, but aren't stack probes entirely predicated on having working guard pages? I.e. they only exist to guarantee that the guard page is accessed before anything else, when a frame is larger than the page.