This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/5] __fdelt_chk: Removed range check
- From: Allan McRae <allan at archlinux dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, Andreas Jaeger <aj at suse dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 06 May 2013 09:13:54 +1000
- Subject: Re: [PATCH 1/5] __fdelt_chk: Removed range check
- References: <CAHGf_=qewv9SqnjRei0NXuODc_ZW0erm5JkBb1r6T+kgGkuK=w at mail dot gmail dot com> <51843C3D dot 7010701 at archlinux dot org> <518670E1 dot 9040006 at redhat dot com>
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).
Allan