Bug 621302

Summary: [abrt] openswan-2.6.24-7.el6: intel_aes_decrypt_cbc_128: Process /usr/libexec/ipsec/pluto was killed by signal 11 (SIGSEGV)
Product: Red Hat Enterprise Linux 6 Reporter: Mike Khusid <mkhusid>
Component: nss-softoknAssignee: Elio Maldonado Batiz <emaldona>
Status: CLOSED CURRENTRELEASE QA Contact: Miroslav Vadkerti <mvadkert>
Severity: medium Docs Contact:
Priority: high    
Version: 6.0CC: avagarwa, caillon, ddumas, drepper, emaldona, jane.lv, jofernan, jrieden, jvillalo, luyu, sgrubb, syeghiay, tmraz
Target Milestone: rcKeywords: RHELNAK
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: abrt_hash:becd161bde97451270fd6c7a3dd79dd5b42811d3
Fixed In Version: nss-softokn-3.12.4-19.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 637948 657042 (view as bug list) Environment:
Last Closed: 2010-11-10 21:15:25 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: 508787, 637948    
Attachments:
Description Flags
File: backtrace
none
Turns off intel HW acceleration for AES none

Description Mike Khusid 2010-08-04 17:54:40 UTC
abrt version: 1.1.10
architecture: x86_64
Attached file: backtrace
cmdline: /usr/libexec/ipsec/pluto --nofork --secretsfile /etc/ipsec.secrets --ipsecdir /etc/ipsec.d --use-netkey --uniqueids --nat_traversal --virtual_private oe=off --nhelpers 0
component: openswan
crash_function: intel_aes_decrypt_cbc_128
executable: /usr/libexec/ipsec/pluto
kernel: 2.6.32-52.el6.x86_64
package: openswan-2.6.24-7.el6
rating: 4
reason: Process /usr/libexec/ipsec/pluto was killed by signal 11 (SIGSEGV)
release: Red Hat Enterprise Linux Workstation release 6.0 Beta (Santiago)
time: 1280943392
uid: 0

How to reproduce
-----
1. Configured NetworkManager-openswan per bug 614250
2. Tried to connect

Comment 1 Mike Khusid 2010-08-04 17:54:42 UTC
Created attachment 436613 [details]
File: backtrace

Comment 2 Mike Khusid 2010-08-04 18:03:03 UTC
Using NetworkManager-openswan-0.8.0-3.20100411git.el6.x86_64

Comment 4 RHEL Program Management 2010-08-04 18:27:44 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 5 Avesh Agarwal 2010-08-05 11:42:58 UTC
NetworkManager-openswan-0.8.0-5.20100411git.el6 and openswan-2.6.24-8.el6 are the latest versions. Could you please try if the issue still happens with these latest versions?

Comment 6 Avesh Agarwal 2010-08-05 12:15:18 UTC
Just looking at the backtrace, it says:

intel-aes.s: No such file or directory. 
in intel-aes.s
 
It seems little surprising why it is happening.

Comment 7 Mike Khusid 2010-08-05 14:57:06 UTC
Not sure what intel aes is, but FYI I have related kernel modules loaded.

$ lsmod | grep aes
aesni_intel            12337  3 
cryptd                  7940  2 aesni_intel
aes_x86_64              7880  1 aesni_intel
aes_generic            27575  2 aesni_intel,aes_x86_64

I will test with newer packages shortly

Comment 8 Mike Khusid 2010-08-05 15:16:47 UTC
Reply to comment 5: tested with updated packages, see bug 621594?

Comment 9 Mike Khusid 2010-08-05 15:17:05 UTC
*** Bug 621594 has been marked as a duplicate of this bug. ***

Comment 10 Avesh Agarwal 2010-08-05 15:30:29 UTC
Thanks for the info. It seems aesni_intel is some module that I do not have on my system. As Steve Grubb told that you are using a hardware accelerator and this module may be related to this. Can I get access to your system (if possible) or some other similar system for reproducing this issue? I am also trying to contact QA people if they can provide ma a similar system to debug this issue.

Comment 14 Tomas Mraz 2010-08-05 21:22:46 UTC
The assembler code in the NSS that supports the aes-ni instruction set incorrectly assumes that the encrypted/decrypted data address is aligned to 16 bytes. It then crashes on unaligned memory access on pxor instruction.

Comment 15 Elio Maldonado Batiz 2010-08-05 21:37:09 UTC
The intel-aes.s contains assembly code to take advantage of special instructions Intel has to accelerate AES. The code was tested with an emulator as we didn't have real hardware yet. Aftrewards and since nss-softokn 3.12.4 was submitted for FIPS and was released some problems where discovered once real hardware became available. The upstream Makefile has the Intel hardware acceleration for aes disabled whereas ours doesn't. I don't think the problems have been solved yet judging the fact that even the latest upstream has it disabled. I could make an nss-softokn scratch build with this disabled to test that this is the case.

Comment 23 Denise Dumas 2010-08-06 18:21:12 UTC
Great - thanks so much, guys. If you can set the dev-ack, I'll go hunt remaining flags so this can build officially and get pulled in to a nightly before snap 11.

Comment 24 Elio Maldonado Batiz 2010-08-06 18:34:21 UTC
Created attachment 437230 [details]
Turns off intel HW acceleration for AES

This is work-around until the permanent fix has been accepted.

Comment 29 Miroslav Vadkerti 2010-08-19 17:33:55 UTC
VERIFIED as fixed in nss-softokn-3.12.4-19.el6. See private comment 28 for details.

Comment 30 Ulrich Drepper 2010-08-20 15:38:29 UTC
Really fixed or worked around?  If it's the later I might take another stab at it.

Comment 31 Tomas Mraz 2010-08-20 15:53:14 UTC
Worked around by disabling the aes-ni implementation in nss.

Comment 32 Ulrich Drepper 2010-08-20 16:04:34 UTC
Then the bug shouldn't be closed or at least a new one opened to get the correct patch.  In case somebody does that please cc: me.

Comment 33 Elio Maldonado Batiz 2010-08-20 16:16:22 UTC
Yes, we should clone this bug as this disabling was meant only as a temporary workraound to get the snaphot out until the real fix is ready. The true fix is upstream as part of nss-3.12.8 which we plan to submmit for FIPS revalidation as soon as review and testing of this, and other fixes, is complete.

Comment 34 releng-rhel@redhat.com 2010-11-10 21:15:25 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.