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 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


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