Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 909402

Summary: cannot kdump to remote server with fips=1 on RHEL 6
Product: Red Hat Enterprise Linux 6 Reporter: Jim Lyle <jlyle>
Component: kexec-toolsAssignee: Baoquan He <bhe>
Status: CLOSED ERRATA QA Contact: Guangze Bai <gbai>
Severity: high Docs Contact:
Priority: high    
Version: 6.3CC: ccui, gbai, jthompso, notting, rsawhill, ruyang, szhou, tmraz, vgoyal, yshao
Target Milestone: rc   
Target Release: 6.5   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: kexec-tools-2.0.0-262.el6 Doc Type: Enhancement
Doc Text:
Feature: Add fips related to fips support Reason: In RHEL6, SSH FIPS support is not complete. In this patch, add the relevant library files and .hmac files to kdump kernel. Result (if any): With these files adding, kdump can work well under SSH FIPS mode.
 Story Points: ---
Clone Of:
: 920931 (view as bug list) Environment:
Last Closed: 2013-11-21 08:17:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 835616, 920931, 960070    

Description Jim Lyle 2013-02-08 16:52:11 UTC 
Description of problem:
kdump to remote server results in error message

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. configure FIPS on two servers (server 1 and server 2)
2. configure kdump to save to server 1
3. enable sysrq on server 2   
4. trigger dump by  #echo c > /proc/sysrq-trigger on server 2

  
Actual results:
Without fips=1 in force on the boot command line, kdump works normally.  With it enabled (and prelinking turned off as required), everything appears to go normally up to the point where it should begin dumping over SSH and then if fails with the below error:

Saving to remote location [user@host]
1+0 records in
1+0 records out
fips.c(153): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST FAILURE
ABRT
Free memory/Total memory (free %): 72936 / 113892 ( 64.0396 )
Checking for memory holes                : [100 %] fips.c(153): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST FAILURE
ABRT
Excluding free pages                        : [100 %] 

After that the machine reboots without even a partial dump.



Additional info:

We have set kdump to drop to shell, and ssh to host will not work either in the kdump shell (busybox?)


This was discussed on tech-list:

http://post-office.corp.redhat.com/archives/tech-list/2013-February/msg00025.html

end quote from Tomaz M and Joe T:

I suppose the .hmac files from openssl, openssh, and fipscheck
packages are not copied to the initrd and that is the problem.

quantified here:

 `find / -name *hmac -print` finds no files in the kexec'ed environment (there are 24 such in the actual filesystem including the various *hmac utility binaries).


Expected results:
Generated core to be saved to remote server with no interaction
Comment 1 Tomas Mraz 2013-02-08 17:24:38 UTC 
Reassigning to distribution as I do not know who is responsible for proper creation of the kdump initramfs.

Certainly the .hmac files contained in the openssl, openssh, and fipscheck packages must be included in it.
Comment 2 Joe Thompson 2013-02-11 01:48:25 UTC 
Further info: I tried having a tarball of all the hmac-related files included in the dump initrd -- this worked, but untar'ing it at the busybox prompt did not allow SSH to succeed (same failure as before) so there appears to be more going on than just missing .hmac files.
Comment 5 Joe Thompson 2013-03-01 20:50:12 UTC 
Taking further info from comments by Baoquan He, I was able to add some more files to the initrd filesystem and finally successfully SSH to the destination system from within that environment.  List is below -- this is overkill, but I figured better to include too many than not enough during testing.  I'll start working on paring this down, e.g. by removing things like man pages.

-----

/boot/.vmlinuz-2.6.32-279.19.1.el6.x86_64.hmac
/lib64/ld-2.12.so
/lib64/ld-linux-x86-64.so.2
/lib64/libc-2.12.so
/lib64/libcrypt-2.12.so
/lib64/.libcryptsetup.so.1.1.0.hmac
/lib64/.libcryptsetup.so.1.hmac
/lib64/libcrypt.so.1
/lib64/libc.so.6
/lib64/libdl-2.12.so
/lib64/libdl.so.2
/lib64/libfipscheck.so.1
/lib64/libfipscheck.so.1.1.0
/lib64/.libfipscheck.so.1.1.0.hmac
/lib64/.libfipscheck.so.1.hmac
/lib64/.libgcrypt.so.11.hmac
/lib64/libnspr4.so
/lib64/libplc4.so
/lib64/libplds4.so
/lib64/libpthread-2.12.so
/lib64/libpthread.so.0
/lib64/libz.so.1
/lib64/libz.so.1.2.3
/sbin/.cryptsetup.hmac
/usr/bin/fipscheck
/usr/bin/.fipscheck.hmac
/usr/bin/fipshmac
/usr/bin/sha1hmac
/usr/bin/sha256hmac
/usr/bin/sha384hmac
/usr/bin/sha512hmac
/usr/bin/.ssh.hmac
/usr/lib64/hmaccalc/
/usr/lib64/hmaccalc/sha1hmac.hmac
/usr/lib64/hmaccalc/sha256hmac.hmac
/usr/lib64/hmaccalc/sha384hmac.hmac
/usr/lib64/hmaccalc/sha512hmac.hmac
/usr/lib64/libcrypto.so.10
/usr/lib64/libcrypto.so.1.0.0
/usr/lib64/.libcrypto.so.1.0.0.hmac
/usr/lib64/.libcrypto.so.10.hmac
/usr/lib64/libnss3.so
/usr/lib64/libnssutil3.so
/usr/lib64/libsmime3.so
/usr/lib64/libssl3.so
/usr/lib64/libssl.so.10
/usr/lib64/libssl.so.1.0.0
/usr/lib64/.libssl.so.1.0.0.hmac
/usr/lib64/.libssl.so.10.hmac
/usr/lib64/python2.6/hmac.py
/usr/lib64/python2.6/hmac.pyc
/usr/lib64/python2.6/hmac.pyo
/usr/sbin/.sshd.hmac
/usr/share/doc/hmaccalc-0.9.12/
/usr/share/doc/hmaccalc-0.9.12/LICENSE
/usr/share/doc/hmaccalc-0.9.12/README
/usr/share/man/man8/sha1hmac.8.gz
/usr/share/man/man8/sha256hmac.8.gz
/usr/share/man/man8/sha384hmac.8.gz
/usr/share/man/man8/sha512hmac.8.gz
Comment 16 errata-xmlrpc 2013-11-21 08:17:41 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1576.html