Closed Bug 1635625 Opened 5 years ago Closed 4 years ago

NSS 3.52 breaks build on ppc64 elfv1

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Version:
3.52
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1642174

People

(Reporter: pkubaj, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

nss-3.52.1:20200605-130422.log (Gentoo, ppc32, PowerMac G4 DP)
730.52 KB, text/x-log
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.23 Safari/537.36

Steps to reproduce:

I tried to install security/nss port on FreeBSD 12.1-RELEASE on powerpc64.

Actual results:

gmake[4]: Entering directory '/wrkdirs/usr/ports/security/nss/work/nss-3.52/nss/lib/freebl'
rm -f FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/libfreeblpriv3.so
gcc9 -Wl,-Bsymbolic -shared -Wl,-soname -Wl,libfreeblpriv3.so -pthread -Wl,--version-script,FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/freeblpriv.def -Wl,-Bsymbolic -o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/libfreeblpriv3.so FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/freeblver.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ldvector.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sysrand.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha_fast.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/md2.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/md5.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha512.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/cmac.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/alghmac.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/rawhash.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/alg2268.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/arcfour.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/arcfive.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/crypto_primitives.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/blake2b.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/desblapi.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/des.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/drbg.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/chacha20poly1305.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/cts.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ctr.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/blinit.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/fipsfreebl.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/gcm.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/hmacct.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/rijndael.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/aeskeywrap.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/camellia.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dh.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ec.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecdecode.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/pqg.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/rsa.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/rsapkcs.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/shvfy.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/tlsprfalg.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/seed.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/jpake.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/mpprime.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/mpmontg.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/mplogic.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/mpi.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/mp_gf2m.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/mpcpucache.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecl.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecl_mult.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecl_gf.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecp_aff.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecp_jac.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecp_mont.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ec_naf.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecp_jm.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecp_256.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecp_384.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecp_521.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecp_256_32.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ecp_25519.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/curve25519_32.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/Hacl_Poly1305_32.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/Hacl_Chacha20.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/Hacl_Chacha20Poly1305_32.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/nsslowhash.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/gcm-ppc.o FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha512-p8.o -L../../../dist/FreeBSD12.1_OPT.OBJ/lib -L../../../dist/FreeBSD12.1_OPT.OBJ/lib -lnssutil3 -L../../../dist/FreeBSD12.1_OPT.OBJ/lib -lnspr4 -pthread
/usr/local/bin/ld: FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha512-p8.o: ABI version 2 is not compatible with ABI version 1 output
/usr/local/bin/ld: failed to merge target specific data of file FreeBSD12.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha512-p8.o
collect2: error: ld returned 1 exit status

Expected results:

NSS should build.

The problem is that nss/lib/freebl/sha512-p8.s literally specifies ".abiversion 2" which forces ELFv2, but FreeBSD switches to ELFv2 only in 13.0.
With this, NSS basically cuts compatibility with ppc64 ELFv1.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Regressed by: 1613238
Has Regression Range: --- → yes

Thanks for the report.

@cand, could you please take a look? If supporting .abiversion 1 isn't simple, perhaps we can somehow check the value and fallback to unaccelerated code for earlier versions.

Flags: needinfo?(cand)

It looks like only older/stable FreeBSD uses that ABI, and it'd be easier to detect it than to edit the asm. However I have no BSD box or experience, Piotr do you think you can do a patch? I will test it on Linux.

I fished this out of google, how FreeBSD checks for it:
${CC} -dM -E - < /dev/null | ${AWK} '/_CALL_ELF/{print "ELFv"$$3}'

Easy enough for the Makefile, but for gyp may be harder.

Flags: needinfo?(cand)

All currently supported FreeBSD versions use that ABI, so I think it's quite important. Only head (master, similar to e.g. Debian sid) switched to ELFv2 and the next stable branch will use ELFv2 as well but I think NSS is important enough to still work on ELFv1.

Yes, this is how you detect ABI version, so if the only issue is changing 2 to 1, that's not a problem. However, different ABI may require other subtle changes in assembly.

@cand

NSS builds fine after changing just abiversion. Can you pass here nss command to test whether it works?

See the cryptohi test suite command in bug 1613238. However running NSS tests requires some system-level config too.

(In reply to cand from comment #3)

It looks like only older/stable FreeBSD uses that ABI,

Not sure about GCC but Clang defaults to ELFv1 on big-endian powerpc64, see
https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/llvm/lib/Target/PowerPC/PPCTargetMachine.cpp#L218
https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/lib/Driver/ToolChains/Clang.cpp#L1925

The Linux distros that actively support BE PPC (namely, only Void) are all new ABI. Debian etc dropped BE PPC years ago.

And FreeBSD is dropping ELFv1 as well, but only since 13.0. Previous branches can't be switched because that would break POLA. I'll test whether simply changing abiversion works.

Also, AFAIK Debian still supports PPC BE in sid.

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → --

I can confirm that changing abiversion to 1 makes all tests all pass.

Another issue is that sha512-p8.s is compiled also for ppc (32-bit):
sha512-p8.s: Assembler messages:
sha512-p8.s:6: Error: unknown pseudo-op: .abiversion' sha512-p8.s:13: Error: unknown pseudo-op:.localentry'

It looks like there is already a script in lib/freebl/scripts/gen.sh to properly generate sha512-p8 for a given ppc variant (ppc64 elfv1, ppc64 elfv2, ppc32), however, it's not run by default and the already-generated version is used.

Which build system for the 32-bit error? It's not supposed to be built for 32.

The generated version is used as it's the preferred model, and avoids any possible perl/etc issues. I don't think there's any Linux variant at all actively supporting 32-bit ppc.

Is NSS for FreeBSD only built via the official packaging, ports or main tree or whatever it's called? If so, do you think the generation step could be embedded into the FreeBSD < 13 build commands, instead of adding complexity in NSS build sys? It seems the best way to me, but I don't know what the BSD folks' preferences are.

I use gmake to build.

There ARE Linux distros targeting ppc32:

  1. Debian sid.
  2. Gentoo.
  3. Adelie.
  4. Void.

If that's not enough, then are are also other systems targeting ppc32, like OpenBSD and NetBSD.

Yes, NSS is built via ports tree and it's IMO ok to add extra step, but the maintainer would have to talk here. That said, I can agree that ppc64 elfv1 is only supported by FreeBSD (apart from AIX) and we are already switching from that, but ppc32 has much wider support and there are people using it. So currently you're forcing all the systems supporting ppc32 to workaround that bug which IMO is not ok.

Yes, the 32-bit bug should be fixed in NSS, I didn't mean otherwise. The problem is mainly that someone with such a system needs to make the patch, can't make changes for something I can't test. It may be as simple as moving the ASFILES line into the USE_64 block, but again, needs to be done by someone with such a system.

Regarding Debian, the debian.org/ports.html page says powerpc is discontinued as of Debian 9. Do you have some info saying sid/unstable has re-added it?

It was dropped as a release architecture, meaning it's now in semi-official Debian Ports and has similar status to ppc64 (BE) or hurd-i386. But it's still supported.

Nope, you don't need ppc32 hardware to test it (I don't have one either). You can build on ppc64 just fine. If you're on ppc64el, you can just make ppc32 VM.

VM is good news, however I don't have the time to set up one in the near future.

OK, but in that case please don't do any further changes without testing them properly whether they work.

Please understand the priorities: ppc64le matters, Linux matters. ppc32 is "best effort", I won't be spending a lot of time on it in any case, and I don't promise to do such tests at all. (this is my personal stance, not Mozilla's - for Mozilla, even ppc64le is lower priority)

I'm just asking you not to break more things than you fix. If you don't want to do proper testing then just make sure that the features you add end up only on ppc64le.

That was the intention of the patch. Yet you can't know for sure whether there's a small mistake affecting some minority platform you don't use. That's why we need users of such niche platforms to report issues and provide patches.

ppc32 is mainly old, pre-64-bit macs; someone using BSD on them is even more rare. Calling support for such "proper testing" is slight hyperbole.

The severity field is not set for this bug.
:jcj, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jjones)

Piotr, please try the patch at https://bugzilla.mozilla.org/attachment.cgi?id=9153100 .

I didn't try it yet, but I can already see it won't work on FreeBSD with elfv2. The reason is that there's no GCC there installed by default, we switched to Clang. There is GCC in the ports tree, but then it's installed as gcc${MAJOR_VERSION} (e.g. gcc9 or gcc10). You should probably change gcc to ${CC}.

Good point, replaced with CC.
https://bugzilla.mozilla.org/attachment.cgi?id=9153128

Greetings! Got here doing some research for this Gentoo downstream bug report: https://bugs.gentoo.org/722110

Just tested cand's [PATCH v2] which fixes the nss-3.52 build problem on my Talos II (Gentoo, ppc64 BE setup) perfectly well. Thanks @cand!

If it is of interest I could test ppc32 specific patches too on a PowerMac G4 DP or on the Talos II running a ppc32 setup (which is in fact a clone of my G4's root partition).

The patch may also fix ppc32, but that's just a guess, I haven't tested such. If it's quick for you to try, please do.

Hm... Just built nss-3.52.1 on Gentoo on the G4 DP without issues, no patch needed here. I'll attach the build.log.

Oh, good to hear. That means FreeBSD must be using a different "as", perhaps llvm's, and it is more strict than GNU's. The extra as file was included in your build too, but your as did not error on it.

Ah, I actually resolved the 32-bit issue. It turned out that the ancient GCC 4.2 has problems with it, but GCC9 (and LLVM) is just fine. So please disrecard this problem.

64-bit ELFv1, however, is valid, and your patch solves the build issue.

It looks like this is close to a solution in bug 1642174. Closing as duplicate - thanks for the report.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(jjones)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: