You didn't specify what subtarget image You used. If You are using generic image then it's self-inflicted, if legacy or geode is used, then it's a bug in the package and should be reported in https://github.com/openwrt/packages/issues.
This can't be compared if You are using different image for both boards. And if You tried to use same image, very likely the newer CPU on APU board simply supports that opcode.
If there's a "leak" from host environment during package build, testing on different arch like arm or mips should reveal if that's the case.
I used geode target as it was specifically made for this board. Utility itself starts well, it generates exception when it starts generating certificate after collecting entropy.
I can't report the bug to github because I write from a country which was sanctioned by the US and I'm too lazy to use VPN, because openwrt's VPN solutions are kinda buggy (like this)
@tmn505 that was just an excuse. I'm having hard time setting up reliable VPN solution for OpenWRT. Actually I was trying to set up CA for libreswan. But since it depends on nss... well I failed a bit again (like with WireGuard). I could have generated those on another machine but libreswan depends on libnss (it stores certificates in database)... so I thought it may generate similar problems during regular libreswan operation
sorry, never actually used the nss utils and certificates, only the psk options, so don't know if I can be of help, it was a real pain to port the nss anyway but I really wanted libreswan
Well, I quick-checked certool in Debian on i386 (on same Alix board) and it worked fine. Not the same version I must admit, but it works. So, clearly something is wrong with compilation environment. Or a specific bug which was already addressed in Debian.
@jow seems to be right on this, the only i386 device that I have is a via cpu where I also use the ipsec vpn based on it's AES cpu acceleration and seems that it's working fine
I guess I could try something
root@remser2net:~# certutil -N -d sql:${HOME}/temp
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.
Enter new password:
Re-enter password:
root@remser2net:~# certutil -S -x -n "Router CA" -s "O=Router,CN=Router CA" -k rsa -g 4096 -v 12 -d sql:${HOME}/temp -t "CT,," -2
Enter Password or Pin for "NSS Certificate DB":
A random seed must be generated that will be used in the
creation of your key. One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.
To begin, type keys on the keyboard until this progress meter
is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
Continue typing until the progress meter is full:
|************************************************************|
Finished. Press enter to continue:
Generating key. This may take a few moments...
Is this a CA certificate [y/N]?
y
Enter the path length constraint, enter to skip [<0 for unlimited path]: >
Is this a critical extension [y/N]?
root@remser2net:~# cat /proc/cpuinfo | more
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 13
model name : VIA Eden Processor 1000MHz
VIA has specific CPU instruction set in their processors called Padlock, which supports AES, so no wonder it works. AMD Geode has separate AES accelerator that's why it is not working.
According to this Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875694, AES detection looks to be fixed upstream long ago, so something in OpenWrt build is not properly configured.
Maybe it was at some point but the nss-3.76 release does not appear to have any sophisticated detection logic. As soon as the target uname is i386 or x86_64, the gcm-x86.c and aes-x86.c objects are unconditionally added and built with -mpclmul and -maes which also implies usage of SSE2 instructions.
From a cursory look, I neither could find a more fine grained detection logic, nor any option to turn off this behavior...
Maybe passing a CPU_ARCH of i486 to bypass feature detection would be a way, but who knows what else gets disabled then...
Indeed, it hadn't changed much since then. I still wonder how does that work in Debian case, since I don't see any logic for that in the package recipe tarball.
That would be good option, but we need to patch that Makefile for our explicit case (geode) and mark package as nonshared, since legacy target is built with same toolchain. And/Or maybe extending coreconf/Linux.mk with our case. There are also files like build.sh, nss.gyp and exports.gyp. I'm not familiar with that build system, so I leave it to @lucize.
Am I right, that this condition should be false if CPU_ARCH is i586? Because uname -m says i586. I am a bit confused, because some packages for geode come from i386_pentium_mmx and other from x86_geode platform. Maybe that package (see very bottom) should be compiled for x86_geode (NSS and linked packages)?
