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 kernel. 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, realizing that it does not work, rolling everything back, setting up a test bed, spending 1 day 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 distribution. 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 production servers if indeed those servers can remain in production! Specifically: 1. There needs to be something in the description of the security advisory that explains this problem -- I do not expect RedHat to be aware of each and every piece of 3rd party 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 new distribution. 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 etc, right? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Upgrade machine from kernel-2.4.18-10 to 2.4.18-17.7.x 2.Recompile openafs-1.2.7-rh7.3.1.src.rpm 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 depmod: sys_call_table 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 restart. AFS and the latest kernel does not play together. So security advisory cannot be implemented. Expected Results: Should have been able to continue with life as we have been doing 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. Additional info:
"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 methodology. 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 and 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. Best regards, Deniz
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.