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: [PATCH 1/5] __fdelt_chk: Removed range check


On 05/06/2013 12:33 AM, Allan McRae wrote:
>> All answers point to "POSIX APIs" with strict POSIX checking
>> when using _FORTIFY_SOURCE with the option to define
>> _FORTIFY_SOURCE_RELAXED_FD_SETSIZE (or something) to disable
>> the checks when expecting Linux/BSD APIs.
>>
>> Does that make sense?
> 
> I think so...  Especially when I combine it with you comment earlier in
> the thread:
> 
> On 01/05/13 12:25, Carlos O'Donell wrote:
>> This is not sufficiently conservative. We want it the other
>> way around. A simple recompile of ruby should result in
>> a ruby that no longer needs to disable _FORTIFY_SOURCE
>> to work around FD_SETSIZE checks.
> 
> So, programs that were build with -U_FORTIFY_SOURCE because of this
> issue would just be rebuilt with the define
> _FORTIFY_SOURCE_RELAXED_FD_SETSIZE.  All existing programs using
> _FORTIFY_SOURCE would not need anything done.

Correct, they would build with -D_FORTIFY_SOURCE_WHATEVER in addition
to removing -U_FORTIFY_SOURCE, thus if -D_FORTIFY_SOURCE was used then
they would get relaxed FD_SETSIZE checking.

The annoying bit is that we've had this check for some time now,
at least 2.17. So now projects will need a configure check to detect
if glibc supports relaxed checking, use that, otherwise disable
_FORTIFY_SOURCE for the entire compiled file. We should really
write up a wiki page showing how to check for the new relaxed checking.

> If I understood that idea correctly, that approach definitely sounds
> much better.  Nothing is changed and the situation gets no worse if no
> software is rebuilt and only better if it does.

The definition of worse depends on your requirements.

The false positives are still present, but should be
fixed easily once detected.

Cheers,
Carlos.



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