Hello!

On powerpc and ppc64, nss is still being built with -mcrypto and -mvsx which
generates code with Crypto and VSX instructions not supported on powerpc and
ppc64.

Normally, the build system should automatically detect the host platform and
set NSS_DISABLE_CRYPTO_VSX=1 for powerpc and ppc64, but that doesn't seem to
work at the moment.

Thus, the following patch will explicitly set NSS_DISABLE_CRYPTO_VSX=1 in
debian/rules, forcing Crypto and VSX instructions to be disabled on powerpc
and ppc64.
--- debian/rules.orig   2021-11-02 02:34:06.000000000 +0100
+++ debian/rules        2022-02-08 10:18:14.805090667 +0100
@@ -71,6 +71,7 @@
        OBJDIR_NAME=OBJS \
        $(and $(filter 64,$(shell dpkg-architecture -qDEB_HOST_ARCH_BITS)),USE_64=1) \
        $(and $(filter x32,$(shell dpkg-architecture -qDEB_HOST_ARCH)),USE_X32=1) \
+       $(and $(filter powerpc ppc64,$(shell dpkg-architecture -qDEB_HOST_ARCH)),NSS_DISABLE_CRYPTO_VSX=1) \
        $(NULL)

 NSS_TOOLS := \

Could you apply the change for the next upload?

Thanks,
Adrian

I thought the code built with -mcrypto -mvsx was behind runtime
detection?

Mike

Hello!

As far as I know, it's not. We had user reports about running into SIGILL
on powerpc and ppc64 targets when running on older hardware. [1]

This is why I added the possibility to turn off VSX and Crypto in NSS upstream
in the first place. [2][3]

Adrian

Hi,

On Thu, 10 Feb 2022 09:07:05 +0100 John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:

 > On 2/10/22 03:22, Mike Hommey wrote:
 > > I thought the code built with -mcrypto -mvsx was behind runtime
 > > detection?
 >
 > As far as I know, it's not. We had user reports about running into SIGILL
 > on powerpc and ppc64 targets when running on older hardware. [1]
 >
 > This is why I added the possibility to turn off VSX and Crypto in NSS
upstream
 > in the first place. [2][3]

I can confirm a reproducible crash in libnss3 / powerpc (32-bit) due to
illegal instruction on my PowerMac G5 (970MP). A quick way to trigger it
is to run 'ecryptfs-wrap-passphrase <file>' which calls libnss3's
'rijndael_encryptBlock128' and crashes on encountering the instruction
'lxvw4x', which was only introduced in version 2.06 of the
specification, so POWER7 and later.

All other code that I've encountered in the binary packages for the
'powerpc' architecture builds works fine so I assume that the 2.06
version of the specification isn't a new baseline for building these
packages (it wouldn't make sense on 32-bit PowerPC anyway to raise the
baseline to POWER7's instruction set).

Interestingly enough rebuilding the package on my 970MP produces
different assembly code, omitting the 'lxvw4x' instruction and this
rebuilt package works fine with my CPU, no illegal instruction. So the
host CPU's model and capabilities affects the assembly code of the built
package, which I assume is not what one should expect?

This instruction seems to be the result of auto-vectorization by gcc, so
likely there's some '-mcpu=native' condition in combination with
optimization options enabling auto-vectorization that produces the
instruction 'lxvw4x' when the file 'nss/lib/freebl/rijndael.c' is
compiled. Specifically around line 584 where it crashes:
584:        COLUMN_3(state) = *((PRUint32 *)(pIn + 12)) ^ *roundkeyw++;

I'm attaching a crash log and disassembly of the function
'rijndael_encryptBlock128' from the current debian binary package in
'sid' (version 3.96-1):
     libnss3_3.96-1_crash_disass_upstream.txt

...and a disassembly of ''rijndael_encryptBlock128' from a package that
I rebuilt on my own machine with no changed parameters (simple 'apt
source --compile libnss3'):
     libnss3_3.96-1_disass_rebuilt.txt

Best regards,

- Erik