Bug#1005164: nss: Please buildd with NSS_DISABLE_CRYPTO_VSX=1 on powerpc and ppc64

[Erik Larsson]

Hi,

On Thu, 10 Feb 2022 09:07:05 +0100 John Paul Adrian Glaubitz 
 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 ' 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
$ gdb --args ecryptfs-wrap-passphrase asdf
GNU gdb (Debian 13.2-1) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ecryptfs-wrap-passphrase...
Reading symbols from 
/usr/lib/debug/.build-id/d8/d1e871d83a1f9276b85ed0292169652b01e59a.debug...
(gdb) run
Starting program: /usr/bin/ecryptfs-wrap-passphrase asdf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
Passphrase to wrap: 
Wrapping passphrase: 

Program received signal SIGILL, Illegal instruction.
rijndael_encryptBlock128 (cx=cx@entry=0x444060, output=output@entry=0xfffef808 
"", input=input@entry=0xfffef7b4 "asdf") at rijndael.c:584
584 rijndael.c: Filen eller katalogen finns inte.
(gdb) bt
#0  rijndael_encryptBlock128 (cx=cx@entry=0x444060, 
output=output@entry=0xfffef808 "", input=input@entry=0xfffef7b4 "asdf") at 
rijndael.c:584
#1  0xf7906ef0 in rijndael_encryptECB (cx=0x444060, output=0xfffef808 "", 
outputLen=, maxOutputLen=, input=0xfffef7b4 
"asdf", inputLen=16)
at rijndael.c:753
#2  0xf7907ba4 in AES_Encrypt (cx=, output=, 
outputLen=, maxOutputLen=, input=, 
inputLen=)
at rijndael.c:1174
#3  0xf7ce2158 in AES_Encrypt (cx=0x444060, output=0xfffef808 "", 
outputLen=, maxOutputLen=, input=, 
inputLen=)
at loader.c:498
#4  0xf7cbd304 in NSC_EncryptUpdate (hSession=, pPart=0xfffef7b4 
"asdf", ulPartLen=16, pEncryptedPart=0xfffef808 "", 
pulEncryptedPartLen=0xfffef6e0) at pkcs11c.c:1508
#5  0xf7de7f08 in PK11_CipherOp (context=0x442930, out=, 
outlen=0xfffef740, maxout=80, in=0xfffef7b4 "asdf", inlen=16) at pk11cxt.c:913
#6  0x003b7e10 in ecryptfs_wrap_passphrase () from 
/lib/powerpc-linux-gnu/libecryptfs.so.1
#7  0x00400838 in main (argc=, argv=) at 
ecryptfs_wrap_passphrase.c:83
(gdb) disass
Dump of assembler code for function rijndael_encryptBlock128:
   0xf7905fb0 <+0>: stwur1,-160(r1)
   0xf7905fb4 <+4>: mflrr0
   0xf7905fb8 <+8>: bcl 20,4*cr7+so,0xf7905fbc 

   0xf7905fbc <+12>:

Bug#1060922: Status of debian-ports

[Erik Larsson]

On Wed, 31 Jan 2024 07:44:57 +0100 Christoph Biedl 
 wrote:

> Christoph Biedl wrote...
>
> > Looking at
> >
> > https://snapshot.debian.org/archive/debian-ports/
> >
> > it seems debian-ports was not updated for almost half a year now. If
> > that was just an error, please fix it. If it was discontinued by
> > intention, please place according notices - or better, re-consider your
> > decision: For release architectures, there's at least archive.d.o to
> > access some older versions of packages, although in a two-year interval
> > only. For the ports, there's plain nothing.
>
> Having snapshots of the debian ports is important to me. As there was no
> officical reaction of any kind, I've started running my own archive,
> using filesystem snapshots. However, I do not intend to make this a
> public service as I lack the ressources to do this in a sane way, also
> this would only be understood as a competition, life is to short for
> that.
>
> It you, future reader, need access to a particular file, drop me a line.
> As processing will have to be done by hand, answers might take a while.

I also have this problem, and I've also started to archive packages for 
ports architectures that I actively use. Having to resort to this is 
very unfortunate. The snapshot.debian.org service is extremely useful 
for the ports especially as many ports regularly break newer package 
versions due to intermittent FTBS issues that cause the 'all' packages 
to be out of sync with the arch-specific ones.
Having access to the recent history on snapshot.debian.org means that 
you can fetch the matching 'all' package version and fix the problem.


If it's an issue of the ports architectures taking up too much disk 
space on Debian's servers, then maybe limit the history of the ports 
archive, but please keep it up to date.
Though if I can afford the disk space on my home NAS then maybe the 
Debian project also could afford it and this is just a glitch. I'm 
hopeful. :)


- Erik

Bug#1021909: libtss2-dev has missing dependencies

[Erik Larsson]

Package: libtss2-dev
Version: 3.2.0-1+b1
Severity: normal
X-Debbugs-Cc: who+deb...@cnackers.org

Dear Maintainer,

The pkgconfig file for tss2-fapi have some Requires.private dependencies
defined. If they are missing pkg-config --exists tss2-fapi fails, which
affects the build of tpm2-pytss.

Would it be possible to include libjson-c-dev, libssl-dev and
libcurl-ssl-dev in the dependencies for libtss2-dev?

/Erik

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.14 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtss2-dev depends on:
ii  libtss2-esys-3.0.2-0  3.2.0-1+b1
ii  libtss2-fapi1 3.2.0-1+b1
ii  libtss2-mu0   3.2.0-1+b1
ii  libtss2-rc0   3.2.0-1+b1
ii  libtss2-sys1  3.2.0-1+b1
ii  libtss2-tcti-cmd0 3.2.0-1+b1
ii  libtss2-tcti-device0  3.2.0-1+b1
ii  libtss2-tcti-mssim0   3.2.0-1+b1
ii  libtss2-tcti-swtpm0   3.2.0-1+b1
ii  libtss2-tctildr0  3.2.0-1+b1

libtss2-dev recommends no packages.

libtss2-dev suggests no packages.

-- no debconf information

Bug#1021170: libegl-mesa0: Extra \$ in libEGL_mesa.so.0.0.0

[Erik Larsson]

Package: libegl-mesa0
Version: 20.3.5-1
Severity: important
File: /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0.0.0

Dear Maintainer,

When testing version 2019.1 of the Schrödinger suite we found a bug in 3 of the 
packages belonging to Mesa; libgbm1, libglx-mesa0 and libegl-mesa0 (reported as 
separat bugs)

We got the following error message

libGL error: MESA-LOADER: failed to open swrast: 
/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or 
directory (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast

The '\$' preceding '${ORIGIN}' does not seem right.

After running a script that checked all files in /lib, /lib64, /usr/lib and 
/usr/libexec
we found 3 files containing the string '\$${ORIGIN}/dri'.

/usr/lib/x86_64-linux-gnu/libgbm.so.1.0.0 (from libgbm1/now 20.3.5-1 amd64)
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0 (from libglx-mesa0/now 
20.3.5-1 amd64)
/usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0.0.0 (from libegl-mesa0/now 
20.3.5-1 amd64)

The string is compiled inte the lib itself, it is not found in the ELF-header.

The easiest way to check if the bug is present is with

grep -a '\\\$\$\{ORIGIN\}/dri' 

We have tested a binary patch as follows:
cd /usr/lib/x86_64-linux-gnu
cp -p libEGL_mesa.so.0.0.0 libEGL_mesa.so.0.0.0.ORIG
cat libEGL_mesa.so.0.0.0.ORIG | sed -e 
's/:\\$${ORIGIN}\/dri:/:\/:${ORIGIN}\/dri:/' > libEGL_mesa.so.0.0.0

(and corresponding to the files from the two other packages).
With that patchs we can start the Schrödinger suite without any errors. Other 
software that we have tried and that use Mesa also work without complaint after 
we patched.

The occurrence of $$ is found in the newer version 22.2.0-1 as well.


-- System Information:
Debian Release: 11.1
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libgbm1:amd64 depends on:
ii  libc6   2.31-13+deb11u4
ii  libdrm2 2.4.104-1
ii  libexpat1   2.2.10-2+deb11u4
ii  libwayland-server0  1.18.0-2~exp1.1

libgbm1:amd64 recommends no packages.

libgbm1:amd64 suggests no packages.

-- no debconf information

Bug#1021169: libglx-mesa0: Extra \$ in libGLX_mesa.so.0.0.0

[Erik Larsson]

Package: libglx-mesa0
Version: 20.3.5-1
Severity: important
File: /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0

Dear Maintainer,

When testing version 2019.1 of the Schrödinger suite we found a bug in 3 of the 
packages belonging to Mesa; libgbm1, libglx-mesa0 and libegl-mesa0 (reported as 
separat bugs)

We got the following error message

libGL error: MESA-LOADER: failed to open swrast: 
/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or 
directory (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast

The '\$' preceding '${ORIGIN}' does not seem right.

After running a script that checked all files in /lib, /lib64, /usr/lib and 
/usr/libexec
we found 3 files containing the string '\$${ORIGIN}/dri'.

/usr/lib/x86_64-linux-gnu/libgbm.so.1.0.0 (from libgbm1/now 20.3.5-1 amd64)
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0 (from libglx-mesa0/now 
20.3.5-1 amd64)
/usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0.0.0 (from libegl-mesa0/now 
20.3.5-1 amd64)

The string is compiled inte the lib itself, it is not found in the ELF-header.

The easiest way to check if the bug is present is with

grep -a '\\\$\$\{ORIGIN\}/dri' 

We have tested a binary patch as follows:
cd /usr/lib/x86_64-linux-gnu
cp -p libGLX_mesa.so.0.0.0 libGLX_mesa.so.0.0.0.ORIG
cat libGLX_mesa.so.0.0.0.ORIG | sed -e 
's/:\\$${ORIGIN}\/dri:/:\/:${ORIGIN}\/dri:/' > libGLX_mesa.so.0.0.0

(and corresponding to the files from the two other packages).
With that patchs we can start the Schrödinger suite without any errors. Other 
software that we have tried and that use Mesa also work without complaint after 
we patched.

The occurrence of $$ is found in the newer version 22.2.0-1 as well.


-- System Information:
Debian Release: 11.1
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libgbm1:amd64 depends on:
ii  libc6   2.31-13+deb11u4
ii  libdrm2 2.4.104-1
ii  libexpat1   2.2.10-2+deb11u4
ii  libwayland-server0  1.18.0-2~exp1.1

libgbm1:amd64 recommends no packages.

libgbm1:amd64 suggests no packages.

-- no debconf information

Bug#1021168: libgbm1: Extra \$ in libgbm.so.1.0.0

[Erik Larsson]

Package: libgbm1
Version: 20.3.5-1
Severity: important
File: /usr/lib/x86_64-linux-gnu/libgbm.so.1.0.0

Dear Maintainer,

When testing version 2019.1 of the Schrödinger suite we found a bug in 3 of the 
packages belonging to Mesa; libgbm1, libglx-mesa0 and libegl-mesa0 (reported as 
separat bugs)

We got the following error message

libGL error: MESA-LOADER: failed to open swrast: 
/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or 
directory (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast

The '\$' preceding '${ORIGIN}' does not seem right.

After running a script that checked all files in /lib, /lib64, /usr/lib and 
/usr/libexec
we found 3 files containing the string '\$${ORIGIN}/dri'.

/usr/lib/x86_64-linux-gnu/libgbm.so.1.0.0 (from libgbm1/now 20.3.5-1 amd64)
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0 (from libglx-mesa0/now 
20.3.5-1 amd64)
/usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0.0.0 (from libegl-mesa0/now 
20.3.5-1 amd64)

The string is compiled inte the lib itself, it is not found in the ELF-header.

The easiest way to check if the bug is present is with

grep -a '\\\$\$\{ORIGIN\}/dri' 

We have tested a binary patch as follows:
cd /usr/lib/x86_64-linux-gnu
cp -p libgbm.so.1.0.0 libgbm.so.1.0.0.ORIG
cat libgbm.so.1.0.0.ORIG | sed -e 's/:\\$${ORIGIN}\/dri:/:\/:${ORIGIN}\/dri:/' 
> libgbm.so.1.0.0

(and corresponding to the files from the two other packages).
With that patchs we can start the Schrödinger suite without any errors. Other 
software that we have tried and that use Mesa also work without complaint after 
we patched.

The occurrence of $$ is found in the newer version 22.2.0-1 as well.


-- System Information:
Debian Release: 11.1
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libgbm1:amd64 depends on:
ii  libc6   2.31-13+deb11u4
ii  libdrm2 2.4.104-1
ii  libexpat1   2.2.10-2+deb11u4
ii  libwayland-server0  1.18.0-2~exp1.1

libgbm1:amd64 recommends no packages.

libgbm1:amd64 suggests no packages.

-- no debconf information