> I'm afraid there's a problem in the hardware AES implementation on x32 on
> certain Intel CPUs.
Despite the real cause being known (hardcoded struct offsets in assembly),
no one provided a proper fix yet. I for one don't know AES crypto
instructions well enough, and according to Jed Javis, taking offsets from
the struct is or was problematic with Solaris toolchains.
So here's an updated version of the "just don't use hw aes on x32" patch;
the old one doesn't apply anymore due to code reorganizations.
You update nss really often, thus it's quite a burden to keep r-b-deps
satisfied; even though most people who use x32 don't actually use nss
(beside ceph it's mostly GUI stuff) and thus we need it mostly due to
dependency chains, it would be nice to have it working.
Thus, please apply the interim patch.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism
⠈⠳⣄⠀⠀⠀⠀ (funeral doom metal).
Description: disable Intel AES on x32
Intel AES extensions are broken on x32 due to wrong hardcoded offsets in
assembly; they match the structs on amd64 but not x32. With no proper
fix coming, disable HW AES for now.
--- nss-3.37.1.orig/nss/lib/freebl/Makefile
+++ nss-3.37.1/nss/lib/freebl/Makefile
@@ -224,7 +224,9 @@ ifeq ($(CPU_ARCH),x86_64)
DEFINES += -DMP_IS_LITTLE_ENDIAN
# DEFINES += -DMPI_AMD64_ADD
# comment the next four lines to turn off Intel HW acceleration.
- DEFINES += -DUSE_HW_AES -DINTEL_GCM
+ ifeq (,$(USE_X32))
+ DEFINES += -DUSE_HW_AES -DINTEL_GCM
+ endif
ASFILES += intel-aes.s intel-gcm.s
EXTRA_SRCS += intel-gcm-wrap.c
INTEL_GCM = 1
