This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: [RFC][PATCH] Initial support for C11 Annex K Bounds checking functions


Florian Weimer wrote:
> We need to decide if we want to check the explicit lengths against the compiler-inferred lengths in _FORTIFY_SOURCE mode.
> 
> 
> Errors in length calculations are sufficiently common that I think performing the additional check makes sense, but there might be other opinions. 

You are raising a good point. I'd say that as a general design rule the _s functions should not be less safe than other functions. Let us consider the following example:
char buf[5];
strcpy_s(buf, 6, "test1"); 

strcpy_s would lead to a off-by-one buffer overflow but not raise a runtime contraint violation because it was told that buf has a size of 6. This is bad. If we can do something against that, we have to.

To be more clear, we have to differentiate between two situations:

1) _FORTIFY_SOURCE is not specified by the user. In this case the _s functions have to conform to the behavior mandated by the C standard. Annex K of the C standard precisely defines how a specific _s function has to deal with regard to the size argument given. It does not allow for special behavior when a size argument is specified wrongly. Compile time warnings would still be okay but I'd favor a consistent overall behavior. 

2) _FORTIFY_SOURCE is specified by the user. This allows us to recognize that the buffer is too small and at the same time tells us that the developer wants us to sacrifice standard conformance for buffer overflow protection (i.e., we are allowed to abort a program). In this case we should do something when we recognize that a buffer is too small. A _s function is in many cases a wrapper around the normal function. Thus, it would benefit automatically from _FORTIFY_SOURCE. But the _s function might not always be a wrapper and we certainly get better error messages when having special treatment for _FORTIFY_SOURCE directly in the implementation of the _s function. 

More concretely, I would suggest the following for the _s functions when _FORTIFY_SOURCE is specified.

a) The compiler issues a warning whenever it can determine that the actual buffer size differs from the size argument given to the _s function. The warning is issued regardless of whether the argument size given is bigger or smaller than the actual buffer size. The size argument of an s function is meant to be reflect an object's size and I see no reason to allow anything else.
In any case, the compiler generates a direct invocation of the respective _s function (there are no _chk functions). That is, even if the compiler knows that no buffer overflow can take place it still generates a call to the (slower) _s function. We need that because the _s function might do a couple of other checks. 

b) Inside the _s function, we use __builtin_object_size for computing an object's size. We have to act when the actual object size is smaller then the specified object size or at the latest before causing a buffer overflow. Upon detection of a buffer overflow, the runtime constraint violation handler introduced by Annex K is called. 

--Ulrich


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