abrt version: 1.1.10
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
reason: Process /usr/libexec/ipsec/pluto was killed by signal 11 (SIGSEGV)
release: Red Hat Enterprise Linux Workstation release 6.0 Beta (Santiago)
How to reproduce
1. Configured NetworkManager-openswan per bug 614250
2. Tried to connect
Created attachment 436613 [details]
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. **
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?
Just looking at the backtrace, it says:
intel-aes.s: No such file or directory.
It seems little surprising why it is happening.
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
Reply to comment 5: tested with updated packages, see bug 621594?
*** Bug 621594 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
Created attachment 437230 [details]
Turns off intel HW acceleration for AES
This is work-around until the permanent fix has been accepted.
VERIFIED as fixed in nss-softokn-3.12.4-19.el6. See private comment 28 for details.
Really fixed or worked around? If it's the later I might take another stab at it.
Worked around by disabling the aes-ni implementation in nss.
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.
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.
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.