Hi!
I'm afraid there's a problem in the hardware AES implementation on x32 on
certain Intel CPUs.  This is caught by the testsuite but only when the package
is built on one of such CPUs.  This includes the vs76 buildd but none of
machines I currently have access to.

I've narrowed the problem to intel_aes_*_worker() functions in freebl, their
implementation is in nss/lib/freebl/intel-gcm-x64-masm.asm .  Alas, properly
fixing this would require knowledge of obscure crypto opcodes, which I don't
possess.  Here's a patch that disables this acceleration until someone with
more clue can help.

I've filed the patch upstream (to
https://bugzilla.mozilla.org/show_bug.cgi?id=1062903), but as NSS upstream
releases are quite rare, please apply it in Debian.

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!

Hello,

I can confirm that the last patch proposed in #819349 workaround the
FTBFS of NSS and also fixes the FTBFS of libsrtp2 (bug #958427)

Would it be possible to apply the patch in NSS to workaround the issue then?

Kind regards,

Laurent Bigonville