Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 621302 - [abrt] openswan-2.6.24-7.el6: intel_aes_decrypt_cbc_128: Process /usr/libexec/ipsec/pluto was killed by signal 11 (SIGSEGV)
[abrt] openswan-2.6.24-7.el6: intel_aes_decrypt_cbc_128: Process /usr/libexec...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss-softokn (Show other bugs)
6.0
x86_64 Linux
high Severity medium
: rc
: ---
Assigned To: Elio Maldonado Batiz
Miroslav Vadkerti
abrt_hash:becd161bde97451270fd6c7a3dd...
: RHELNAK
: 621594 (view as bug list)
Depends On:
Blocks: 508787 637948
  Show dependency treegraph
 
Reported: 2010-08-04 13:54 EDT by Mike Khusid
Modified: 2013-04-02 19:43 EDT (History)
13 users (show)

See Also:
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 16:15:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (11.88 KB, text/plain)
2010-08-04 13:54 EDT, Mike Khusid
no flags Details
Turns off intel HW acceleration for AES (680 bytes, patch)
2010-08-06 14:34 EDT, Elio Maldonado Batiz
no flags Details | Diff

  None (edit)
Description Mike Khusid 2010-08-04 13:54:40 EDT
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 13:54:42 EDT
Created attachment 436613 [details]
File: backtrace
Comment 2 Mike Khusid 2010-08-04 14:03:03 EDT
Using NetworkManager-openswan-0.8.0-3.20100411git.el6.x86_64
Comment 4 RHEL Product and Program Management 2010-08-04 14:27:44 EDT
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 07:42:58 EDT
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 08:15:18 EDT
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 10:57:06 EDT
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 11:16:47 EDT
Reply to comment 5: tested with updated packages, see bug 621594?
Comment 9 Mike Khusid 2010-08-05 11:17:05 EDT
*** Bug 621594 has been marked as a duplicate of this bug. ***
Comment 10 Avesh Agarwal 2010-08-05 11:30:29 EDT
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 17:22:46 EDT
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 17:37:09 EDT
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 14:21:12 EDT
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 14:34:21 EDT
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 13:33:55 EDT
VERIFIED as fixed in nss-softokn-3.12.4-19.el6. See private comment 28 for details.
Comment 30 Ulrich Drepper 2010-08-20 11:38:29 EDT
Really fixed or worked around?  If it's the later I might take another stab at it.
Comment 31 Tomas Mraz 2010-08-20 11:53:14 EDT
Worked around by disabling the aes-ni implementation in nss.
Comment 32 Ulrich Drepper 2010-08-20 12:04:34 EDT
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 12:16:22 EDT
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 16:15:25 EST
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.

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