This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 09/12/2013 06:05 PM, Joseph S. Myers wrote:
On Thu, 12 Sep 2013, Joseph S. Myers wrote:(Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not just SIZE_MAX, should be caught, because pointer subtraction cannot work reliably with larger objects. So it's not just when the size or multiplication overflow size_t, but when they overflow ptrdiff_t.)And, to add a bit more to the list of possible ubsan features (is this todo list maintained anywhere?), even if the size is such that operations on the array are in principle defined, it's possible that adjusting the stack pointer by too much may take it into other areas of memory and so cause stack overflow that doesn't get detected by the kernel. So maybe ubsan should imply -fstack-check or similar.
I have on my to-do list to make -fstack-check production-ready, by avoiding unnecessary instrumentation. My initial experiments weren't too successful, but I think it should be possible to greatly reduce its overhead. If everything else fails, the idea is to reuse the Go split stack limit and check against that.
The idea is that this would eventually be enabled in production code, much like -fstack-protector.
I'm quite busy with other work at the moment, and a patch from me is probably months away, though. :-(
-- Florian Weimer / Red Hat Product Security Team
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |