Bug 614382

Summary: hmaccalc not working on ppc64 in non-FIPS mode
Product: Red Hat Enterprise Linux 6 Reporter: Miroslav Vadkerti <mvadkert>
Component: prelinkAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Michal Nowak <mnowak>
Severity: medium Docs Contact:
Priority: high    
Version: 6.0CC: amodra, jakub, jan.kratochvil, lagarcia, mnowak, nickc, ohudlick, syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard:
Fixed In Version: prelink-0.4.3-4.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 614443 (view as bug list) Environment:
Last Closed: 2010-11-10 21:21:56 UTC Type: ---
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: 580448, 609517, 614443    
Attachments:
Description Flags
libfreebl3.so.xz
none
prelink-uo.patch none

Description Miroslav Vadkerti 2010-07-14 10:39:15 UTC
Description of problem:
hmaccalc fails on ppc64 with this error:
# sha1hmac -S
Error ensuring FIPS mode.

FIPS mode is disabled:
#  cat /proc/sys/crypto/fips_enabled
0

How reproducible:
always on the reserved machine

Steps to Reproduce:
1. prelink -u -a
2. sha1hmac -S
  
Actual results:
Error ensuring FIPS mode.

Expected results:
No error

Additional info:
This bug is reported on prelink, because of conversation with nalin (hmacalc maintainer):
On Tue, Jul 13, 2010 at 03:13:27PM -0400, Nalin Dahyabhai wrote:
> Okay, I cut the test case down to the attached, which is happy on
> x86_64, but still fails on the test box.  I still need to trace through
> it on x86_64 to determine where one fails and the other doesn't, though.

With NSS_ENABLE_AUDIT=1 set in the environment, I'm getting log messages
indicating that there's a problem in the self-tests.  It looks like the
self-test involves running
   "/usr/sbin/prelink -u -o - /usr/lib64/libfreebl3.so"
if prelink is installed, calculating the signature over that, and
continuing on from there, more or less the same way hmaccalc does.

The problem seems to be that, for whatever reason, prelink's output
here isn't the same as its input:
  /usr/sbin/prelink -u -a
  yum -y reinstall prelink nss nss-softokn
  /usr/sbin/prelink -u -a
  /usr/sbin/prelink -u -o tempfile /usr/lib64/libfreebl3.so
  cmp tempfile /usr/lib64/libfreebl3.so

That's going to cause the self-signature check in libfreebl3.so to fail,
so I think the problem is somewhere in either nss-softokn and prelink.

Comment 2 Jakub Jelinek 2010-07-14 11:06:45 UTC
This looks like a ld bug on ppc64:

  [22] .toc1             PROGBITS        00000000000609e0 0609e0 000418 00  WA  0   0  8
  [23] .opd              PROGBITS        0000000000060df8 060df8 001cf8 00  WA  0   0  8
  [24] .branch_lt        PROGBITS        0000000000062af0 062c20 000000 00  WA  0   0  8
  [25] .got              PROGBITS        0000000000062af0 062af0 000130 08  WA  0   0  8
  [26] .plt              NOBITS          0000000000062c20 062c20 0005d0 18  WA  0   0  8
  [27] .bss              NOBITS          00000000000631f0 062c20 004490 00  WA  0   0  8

Note that sh_offset of .branch_lt section is incorrect, it should have been 0x62af0 (both to match its sh_addr (modulo any PT_LOAD p_vaddr vs. p_offset difference) and not be bigger than the next section's sh_offset.

Comment 3 Jakub Jelinek 2010-07-14 11:53:21 UTC
Created attachment 431742 [details]
libfreebl3.so.xz

To be precise, this isn't a ld bug, but strip bug.
rpmbuild install uses eu-strip -f to strip debug sections into separate *.debug file, but then /usr/lib/rpm/redhat/brp-strip-comment-note is run on the result
and strips .comment section.  This script uses strip from binutils rather than
eu-strip from elfutils.

Attached is correct libfreebl3.so.  To reproduce:
unxz -c libfreebl3.so.xz > libfreebl3.so
readelf -WS libfreebl3.so | grep -C3 branch_lt
strip libfreebl3.so
readelf -WS libfreebl3.so | grep -C3 branch_lt

Comment 4 Andreas Schwab 2010-07-14 12:03:48 UTC
branch_lt is empty so its address should not really matter.

Comment 5 Jakub Jelinek 2010-07-14 12:10:38 UTC
Can be still reproduced even with today's binutils HEAD.

Comment 6 Jakub Jelinek 2010-07-14 13:50:06 UTC
Created attachment 431776 [details]
prelink-uo.patch

While I still consider this to be a strip/objcopy bug, IMNSHO sh_offset values should be monotonically increasing and for allocated sections
sh_offset should be sh_vaddr - p_vaddr + p_offset for corresponding PT_LOAD segment they are in, and definitely strip/objcopy shouldn't be changing them to a pretty much random value, I'm testing a prelink change to pass through the original file bits for prelink -u -o ... when no .gnu.prelink_undo section is present instead of saving the file into a temporary file and then copying over that temporary file to -o's argument.  This will make prelink more efficient for -u -o ... operation, so is the right thing to do.

Will clone this bug for binutils so that strip/objcopy is fixed for RHEL6.1.

Comment 7 Jakub Jelinek 2010-07-14 14:30:56 UTC
prelink-0.4.3-4.fc14 with this change built for rawhide, for RHEL6 it is waiting for pm_ack.

Comment 10 Alan Modra 2010-07-20 23:52:10 UTC
Fixed on mainline with http://sourceware.org/ml/binutils/2010-07/msg00278.html

I wouldn't rush to backport this into distro sources just yet.  The patch hasn't had a lot of testing and quite likely will break something..

Comment 11 Michal Nowak 2010-07-21 06:25:08 UTC
Alan, this is the prelink part of the bug, the binutils one is here: bug 614443 Anyway, thanks for letting us know.

Comment 12 Jakub Jelinek 2010-07-21 07:06:33 UTC
Thanks, Alan.

Comment 13 releng-rhel@redhat.com 2010-11-10 21:21:56 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.