On 11/5/20 8:29 AM, Jakub Jelinek wrote:
On Thu, Nov 05, 2020 at 08:20:20AM -0700, Martin Sebor via Gcc-patches wrote:
compute_objsize() and the objsz pass are completely independent.
The pass is also quite limited in that it doesn't make use of
ranges. That limitation was also the main reason for introducing
the compute_objsize() function.
I'd love to see the objsize pass and compute_objsize() integrated
and exposed under an interface similar to range_query, with
the information available anywhere, and on demand. I might tackle
As I said multiple times, that would be a serious security hazard.
_FORTIFY_SOURCE protects against some UBs in the programs, and ranges
are computed on the assumption that UB doesn't happen in the program,
so relying on the ranges etc. in there is highly undesirable.
As I think has been pointed out as many times in response, failing
to handle ranges in _FORTIFY_SOURCE, or any expressions that can't
be evaluated at compile time for that matter, is the security gap.
It means that the vast majority of allocated objects (by malloc,
alloca, or VLAs) are unprotected, as are accesses into fixed-size
objects involving nonconstant offsets.
It's only thanks to compute_objsize() GCC diagnoses (but doesn't
prevent) a small subset of buffer overflows involving such accesses
but only those where the lower bound of the access exceeds the upper
bound of the size. It's powerless against those where the overflow
is due to the size of the access exceeding just the lower bound of
the object size but not the upper bound.
This serious _FORTIFY_SOURCE shortcoming was recognized by the Clang
developers and rectified by introducing __builtin_dynamic_object_size.
Martin
