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

["Carlos O'Donell" <carlos at redhat dot com>]

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?

Cheers,
Carlos.