[CentOS-devel] iptables-devel in centos 4.4
R P Herrold
herrold at owlriver.com
Thu Aug 24 21:02:11 UTC 2006
On Wed, 23 Aug 2006, Karanbir Singh wrote:
> Matthew Miller wrote:
>> it's "updated to new snapshot, altering about 100,000 lines
>> of code". Which is it in this case?
>>
>> If it's nearer the former, Milan's request that the newer
>> compiler be used because it fixes a known and serious
>> problem seems quite reasonable.
> here is the changelog:
Let's see what the changes were .... I think it is undecidable
as to the matter of 'reasonableness', in doing a postmortem
> * Tue May 23 2006 Jakub Jelinek <jakub at redhat.com> 3.4.6-3
> - -fvar-tracking fixes needed for SystemTap (BZ#2438)
- not clear which BZ is referred to, but it is not the
Red Hat one; not in the Cygwin one
(http://www.cygwin.com/bugzilla/), not in the Gnu one
(http://gcc.gnu.org/bugzilla/)
> - add workaround for buggy programs that link in their own unwinder
> and reexport it (#192814)
- probably the Red Hat bugzilla, but bug 192814 is
blocked from review by 'mere mortals' in the general public --
This implies a security related matter, which are
definitionally important changes
> - make all globals in libgcc_eh.a hidden, so that newly (incorrectly)
> linked programs can't reexport the unwinder
- no bugzilla reference as to why and what
'incorrectly' linked programs are exporting the unwinder, nor
why that is dangerous (rather than just wrong -- if only
wrong, the problem is in the sources of the misbehaving
program, and would seem to be more properly fixed there,
unless there ARE security overtones). Is the kernel one of the
offenders? -- One cannot say.
> - support -fno-frame-base-loclist option to prevent use of
> DWARF2 location lists in DW_AT_frame_base value (#191041)
- probably the Red Hat bugzilla, but bug 191041 is
also blocked from review by 'mere mortals' in the general public
One has to suspect that there may be dangerous behaviours
being addressed, from the obscure Changelog backreferences.
> Matt, the point is - those changes might have implications
> down the road - I dont have the gcc knowledge to work out
> exactly what those issues might be - and some of them do
> seem to have a direct impact on kernel space stuff ?
and as we see in this case, and after inspection from the
Changelog, and the outlinks it references, that NONE of the
underlying reasoning nor cause for the changes for that GCC
variant may be inspected, without further study than what we
have or can easily access.
It would take further study to reach decideability as to
'reasonable', comparing between patched source trees of the
GCC versions in question to even see what has changed. As I
recall, gcc builds part of its macro expansion set on the fly
during the compile, and so one has to snapshot it from time to
time as well, to see what is changing.
Matt later said:
> So, the RHSA-2006:0617-15-based kernel from yesterday is
> built with the new gcc, and the whole conversation is pretty
> frickin' moot.
I want also to point out that just because a person produces a
binary variant with a header containing the string 'X',
nothing guarantees that the compiler version you THINK
produced that X is truly one that a later appearing X variant
in fact produced -- one can trivially spoof such values;
buildsystems slipstream changes all the time
... we _hope_ is is the same, we hope it is moot, but nothing
at all says that the binary update from June was build with
the similarly version numbered sources released in August.
It need not even be intentional that identical number versions
may hold varying content. Personal buildtrees outside of a
central buildsystem are the rule, not the exception.
>From CentOS' point of view, the most responsible way to
proceed, is to have a reproducable course documented, and to
follow it. _If_ one had a formal confirmaton on a particular
kernel's buildsystem environment (which will not be
forthcoming), or access to the specific GCC sources known to
have been used for the specific binary kernel variant being
compared to, other options might exist. The PNAELV did not
choose to timely make available the asserted gcc variant in
question.
A better approach, the CentOS approach: build using a
toolchain, based on the freely reproducable sources actually
released, and not expose that million user base to unknown
risks with 'likely' used variants without formal provenance.
A downstream user/admin wishing to do so, and to be daring,
may do so, as they see fit, but in turn only harm themself, if
the decision turns out to be ill advised.
- Russ Herrold
More information about the CentOS-devel
mailing list