Re: [PATCH 1/5] __fdelt_chk: Removed range check

[Allan McRae <allan at archlinux dot org>]

On 06/05/13 12:40, Carlos O'Donell wrote:
> On 05/05/2013 07:13 PM, Allan McRae wrote:
>> On 06/05/13 00:46, Carlos O'Donell wrote:
>>> On 05/03/2013 06:37 PM, Allan McRae wrote:
>>>> On 04/05/13 04:30, KOSAKI Motohiro wrote:
>>>>
>>>>> In the other words, either disabling or not disabling, we'll get several pains.
>>>>>
>>>>> 1. If we disable __fdelt_chk and distro doesn't rebuild any packages.
>>>>>    -> it works. but the packages are no longer protected by FORTIFY
>>>>>        until rebuilt.
>>>>>
>>>>> 2. If we don't disable __fdelt_chk and distro doesn't rebuild any packages.
>>>>>    -> Several software based on Linux extensions still may crash.
>>>>>        Maybe this is not an option either.
>>>>>
>>>>> 3. If we disable __fdelt_chk and distro rebuild all packages.
>>>>>    -> No sense. We don't need disable it if distro agree all rebuild.
>>>>>
>>>>> 4. If we don't disable __fdelt_chk and distro rebuild cherry
>>>>>     picked packages.
>>>>>     -> It works. Affected softwares are expected less than twenty.
>>>>>         However the remained problem is, nobody know full lists
>>>>>         of affected packages. And third party software which doesn't
>>>>>         built still may crash.
>>>>>
>>>>> Practically, only (1) and (4) are an option. There are no free lunch either.
>>>>> Thus, I'd like to ask distro developers.
>>>>>
>>>>
>>>> From that, I'd say the (1) is the only option - although it is still not
>>>> ideal...  In all other cases, package built against prior glibc may
>>>> crash and that is not acceptable.
>>>
>>> What leads you to have this opinion? Is it because the false positives are
>>> code patterns that have been supported for a long time on Linux and BSD,
>>> and with the stricter _FORTIFY_SOURCE checks around FD_SETSIZE are now
>>> triggers false positive checks?
>>
>> Essentially.  I suppose the false positives are probably only a minor
>> inconvenience as far as Linux distros go, given most rebuild their
>> entire system when a glibc update happens and others can rebuild the
>> small number of packages that will expose this.  But this can not be so
>> readily handled with third party software.
>>
>> Is there a simple way to check which software will crash with this
>> change?  That way we can assess what is the probability thing will
>> crash?  Perhaps that will give us an idea what the probability third
>> party software will be affected?
>>
>> In the end, my distro will either have to rebuild everything to get back
>> _FORTIFY_SOURCE (option #1) or rebuild the required packages or all
>> packages to fix crashes (options 2 & 4, depending on how easy these are
>> to detect).
> 
> If you had third party software compiled with _FORTIFY_SOURCE, and
> that headers did not have support for enhanced FD_SETSIZE checking
> then your build will not includ references to the checking functions
> and upgrading glibc will not change that.
> 
> If you had third party software compiled with _FORTIFY_SOURCE, and
> that *did* include references to the checking functions, then such
> software may fail if certain FD* macros are called on fd sets that
> are allocated on the heap and are larger than 1024 fds.
> 
> So one argument for relaxing the checking is that poorly tested
> 3rd party software might fail when compiled with _FORTIFY_SOURCE
> and the stricter checks. Granted we have no real way to inform 
> all developers of the new option (other than via a glibc wiki 
> page, announce mailing list and responses to bugs, but that
> won't reach many people).
> 
> IMO the stronger argument for relaxing the check is that this is a
> well accepted BSD and Linux coding pattern and that to not
> support >1024 fds by default in glibc is a failure in 
> _FORTIFY_SOURCE.
> 
> Is that argument strong enough for us to weaken the
> _FORTIFY_SOURCE check?
> 
> It's a significant weakening. It is likely that __bos0 will not
> work in most of the cases, Motohiro-san's examples had only one
> check where it would work, and the fallback is no check.
> 
> Thus we've basically removed the fd set checks.
> 
> Again we're back to the basic question: What does glibc implement?
> 
> Linux/BSD APIs? POSIX APIs?
> 
> What is they conflict? As they do here?
> 
> Which one wins?
> 
> Given the code is in place.
> 
> Given we have fail safe code with possible false positives
> (good for security).
> 
> Given we are a conservative project.
> 
> 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.

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.

Allan