Red Hat Bugzilla – Bug 76289
sys_call_table is not exported - breaks AFS and God knows what else in a "stable", old version
Last modified: 2007-04-18 12:47:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; tr-TR; rv:1.1) Gecko/20021006
Description of problem:
I have recently upgraded 7.3 machines due to the security advisory RHSA-2002:206-12,
which necessitates upgrading the kernel from 2.4.18-10 to kernel-2.4.18-17.7.x
Please note the fact that the kernel major and minor versions are exactly the same.
My expectation in this kind of security advisory/bug fix update is no major
change in functionality.
Well, there is. sys_call_table is no longer exported in this bug fix
This means that my Redhat 7.3 based AFS servers and clients cannot
work since Openafs is dependent on this.
After stopping all AFS daemons, upgrading the kernel, re-compiling OpenAFS,
that it does not work, rolling everything back, setting up a test bed, spending
in various other tests, I finally realize that this design decision
by Alan Cox, which is in some AC patch in some development tree somewhere has made
its way to a security advisory, patch level kernel upgrade for Redhat's 7.3
Please note that the AFS team is aware of the decision in the kernel mailing
list and are
trying to code their way around it. However, there needs to be more than a few
days lapse time
before something flies out of Alan Cox's design table and makes its way into our
if indeed those servers can remain in production!
1. There needs to be something in the description of the security advisory that
this problem -- I do not expect RedHat to be aware of each and every piece of
software people may be running, but not exporting sys_call_table can be mentioned.
2. Is this patch necessary for this security advisory? I am guessing not. Then
why is it
released for REdhat 7.3? I have some test bed machines evaluating Redhat 8.0
and am not
that upset that it broke AFS on 8.0. It is, after all, relatively recent, major
However, I do expect Redhat 7.3 , modulo some needed security updates, to work
as advertised until
Redhat drops support for it. This is the reason why you have release numbers
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Upgrade machine from kernel-2.4.18-10 to 2.4.18-17.7.x
3.rpm -Uvh --force openafs* (needs to be forced as the openafs rpm version no
is the same, just recompiled for later kernel)
4. /etc/rc.d/init.d/afs start -- module loading will fail.
When doing depmod -e on the libafs kernel module, one gets the following error
depmod: *** Unresolved symbols in libafs-2.4.18-17.o
Actual Results: ?? Could not restart the AFS daemons. Had to roll back the
kernel to the old
version, roll back AFS to the version compiled with the old version and
AFS and the latest kernel does not play together. So security advisory cannot be
Expected Results: Should have been able to continue with life as we have been
since we started using REdhat 7.3 as AFS servers and went through
numerous kernel upgrades.
I regard this as a security issue since I am not able to follow
a security advisory because of it.
"However, there needs to be more than a few days lapse time "
they had about a year
btw as far as I know the AFS people now hack around this by looking up the
symbol from the System.map.
The reason the symbol is removed is because modules using it will clash with the
oprofile functionality that got added to this kernel.
>"However, there needs to be more than a few days lapse time "
>they had about a year
OK, the bug report does rant, but I think closing it immediately with this
comment is uncalled for.
Alan Cox did this patch in his tree around April 2002. The following are his own
words regarding this patch:
"Thats not why it was pulled out. Its a deliberate attempt to find out who
is patching the syscall table and sort the results out.
And btw - I've not submitted this to Marcelo, its not something I expect to
see sprung on people in 2.4.19!"
Seeing this patch then spring up on a 2.4.18 level kernel in an older version of
Redhat (7.3) points out a problem with Redhat's release and maintenance
And as per the second comment -- I have searched the archives and found a
comment or two regarding a hack placed in CVS -- BUT:
The current released version of OpenAFS -- 1.2.7 does suffer from this issue
As far as I can see, the CVS addition was still on the level of a hack -- there
was talk of PAG being broken as a result of this change.
So, there is no immediate solution that OpenAFS users can implement with this
kernel, aside from not upgrading to it.
Alan put this patch in his tree after it had been in the RH tree for a months.
During the ENTIRE 7.3 beta cycle and 8.0 beta cycle this symbol was not there.
We enabled it briefly for the 7.3 release especially for openAFS because the
openAFS people said, on lkml, that they needed extra time to fix it. In the
current kernel there is OPROFILE and that unfortionatly conflicts with other
modules that want to do the very depricated and invasive syscall patching.
As for release policy: Red Hat has never and I assume will never guaranteed that
invasive external kernel modules will keep working between releases of the
kernel. We can't do this normally due to the nature and lack of a real internal
kernel interface for modules. Having said that, the Advanced Server release
tries to maintain stability here as much as possible at the expense of much
higher maintenance and testing costs.