This is the mail archive of the 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]

Re: Usage of C11 Annex K Bounds-checking interfaces on GCC

On 12/9/19 8:15 PM, li zi wrote:
Hi All,
We are using gcc in our projects and we found some of the C standard functions (like memcpy, strcpy) used in gcc may induce security vulnerablities like buffer overflow. Currently we have not found any instances which causes such issues.
But we feel better to change these calls to Cll Annex K Bounds-checking interfaces like memcpy_s, strcpy_s etc. By defining a secure calls method (list of func pointers) and allowing application to register the method. I understand that this affects performance because of return value check added for xxxx_s calls, but this will relieve overflow kind of issues from code. And also currently using bounds-checking interfaces is a general industry practice.
Please share your opinion on it, and if any discussion happened in community to do some changes in future.

GCC's Object Size Checking is a non-intrusive solution to
the problem.  It avoids the considerable risk of introducing
bugs while replacing existing calls with those to the _s
functions.  The implementation is restricted to constant
sizes so its effectiveness is a limited, but we have been
discussing enhancing it to non-constant sizes as well, as
Clang already does.  With that, it should provide protection
with an effectiveness comparable to the _s functions but
without any of the downsides.  (Note that GCC's buffer
overflow warnings are not subject to the same limitation.)

Besides Object Size Checking, I would suggest making use of
the new attribute access.  It lets GCC detect (though not
prevent) out-of-bounds accesses by calls to user-defined
functions decorated with the attribute.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]