Description of problem: ardware Certification Test failed with "Error: kernel is tainted (value = 64)" and "Error: The following symbols are used by dm_log_clustered are not on the ABI whitelist." for dm_log_clustered kernel module, There is excerpt of error from info.py: ==================================== OS Version: Red Hat Enterprise Linux Server release 5.3 (Tikanga) Kernel RPM: kernel-xen-2.6.18-128.el5 HTS version 5.2, release 20 + rpm -ql kernel-xen-2.6.18-128.el5 Error: kernel is tainted (value = 64) Boot Parameters: ro root=LABEL=/1 rhgb quiet Error: Kernel check failed. HTS Verify passed Non-Red Hat kernel module dm_log_clustered Red Hat Enterprise Linux RHEL5 ABI -------------------------------- Module: dm_log_clustered Kernel: 2.6.18-128.el5xen Whitelist: /usr/src/kernels/2.6.18-128.el5xen-x86_64/kabi_whitelist Error: The following symbols are used by dm_log_clustered are not on the ABI whitelist. cn_add_callback cn_del_callback cn_netlink_send dm_dirty_log_type_register dm_dirty_log_type_unregister Error: Module check failed : ==================================== Please let us know how to resolve this error to run Hardware Certification Test Program for RHEL5.3. Version-Release number of selected component (if applicable): RHEL5.3(32bit/64bit), hts-5.2.20/hts-5.3.15 (Might be RHEL5.3xen, i686, x86-64 kernels) How reproducible: always Steps to Reproduce: Actual results: Test tool (info.py) reports that kernel is tainted against dm_log_clustered kernel module and symbols in that module is not on ABI whitelist. Expected results: This kernel module is part of RHEL5.3GA kernel, so there should be no error with this kernel module Business impact: Hardware info: Additional info: This error does not occurred on RHEL 4.7. SEE BZ: 481690 for further information This BZ is being filed against HTS.
I think we're mixing a # of issues: #1, tainted value of 64, unless we're just going to ignore all unsigned modules I think this is an important check. What methods does engineering provide to validate which module(s) have caused the taint bit mask to be set? #2, kabi failure, it would seem there are 3 possibilities here, #1 the kernel whitelist should be updated to include the cmirror and other Red Hat shipped modules abi usage, #2 the Red Hat shipped modules should adhere to the kabi whitelist, #3 #1 and #2 are being done and the kabi checker is failing to follow layered symbols. #3, there are packages outside of the kernel that Red Hat ships as part of GA which should be allowed as valid packages to provide Red Hat kernel modules. What is this list such that we can consider how to add them to the info test checks. ... to set expectations due to timing I think we're looking @ v7-1.1/RHEL6 time frame before we could introduce a new fix given that our RC date is next week for v7-1.0/RHEL5.4 time frame.
1. So from my discussions with some kernel engineers we will never be able to sign external kernel modules. So a taint of '64' is going to unavoidable when using cmirror, gfs, etc. 2. This should be fixed in 5.4, those symbols should have been added to the whitelist and shouldn't be a problem anymore. 3. I'm not sure how to solve this issue.
1) the tainted value and key signing issue is understood; however once the bitmask value is set because of RH modules any other unsigned modules get a free ride through support, software certification, and hardware certification, none of which sounds like an acceptable condition. What options can engineering provide? ...otherwise the original engineering work to add an unsigned module value and all of the tooling and support effort to support the field is wasted because it cannot be trusted to have a useful meaning. 2) excellent 3) we (hwcert) can address the issue once we have a package list.
Rob, Do you still need info from me on this?
Hi Debbie, Still looking for an answer to #1 and #3, maybe it goes to Chris instead?
I'm not sure if I can best answer these, but in response to comment #3, I've talked with the kernel engineers and it is not possible (with our current design) to sign kernel modules that are not built with the kernel. So any external kernel modules that are built by redhat or anyone else will taint the kernel. I don't know of any other option that I can provide to help fix this issue. You may need to bring this up with the kernel team.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0702.html
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The Hardware Certification Test for this module works correctly.