Bug 909402 - cannot kdump to remote server with fips=1 on RHEL 6
Summary: cannot kdump to remote server with fips=1 on RHEL 6
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kexec-tools
Version: 6.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: 6.5
Assignee: Baoquan He
QA Contact: Guangze Bai
Depends On:
Blocks: 835616 920931 960070
TreeView+ depends on / blocked
Reported: 2013-02-08 16:52 UTC by Jim Lyle
Modified: 2018-12-03 18:17 UTC (History)
10 users (show)

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.
Clone Of:
: 920931 (view as bug list)
Last Closed: 2013-11-21 08:17:41 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1576 0 normal SHIPPED_LIVE kexec-tools bug fix and enhancement update 2013-11-20 21:39:51 UTC

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:

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
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
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:


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.



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.


Note You need to log in before you can comment on or make changes to this bug.