Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
Forward the missing messages. -- Forwarded message -- From: 王昊然 Date: Fri, 21 Oct 2022 14:09:33 +0800 Subject: Re: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7 To: Maamoun TK Cc: Niels Möller I can confirm this patch worked on my system. 2022-10-20 21:02 GMT+08:00, Maamoun TK : > On Wed, Oct 19, 2022 at 6:22 PM Maamoun TK > wrote: > >> On Wed, Oct 19, 2022 at 5:50 PM Niels Möller >> wrote: >> >>> WHR writes: >>> >>> > I think the Debian architecture I'm using (ppc64) should still >>> supporting >>> > POWER7, but apparently this library was built to use instructions >>> unavailable >>> > on POWER7. >>> >>> Nettle attempts to figure out at runtime which processor features are >>> available. >>> >>> > => 0x3fffb72bedec <+76>:vmrgow v4,v0,v0 >>> >>> The ppc specification says "vmrgow is treated as a Vector >>> instruction in terms of resource availability.", it's not entirely clear >>> to me what that means, and if checking for altivec support should be >>> enough. >>> >> >> I don't have access to log file or bug report but I'm assuming that the >> usage of "vmrgow/vmrgew" in chacha-2core.asm triggers this bug since both >> instructions are only available on POWER8+ >> >> I'll investigate more about the issue besides the possibility of >> utilizing >> "vmrghw/vmrglw" instead. >> > > It seems only the usage of "vmrgow/vmrgew" causes the issue. I pushed a MR > to the main repository that resolves the bug > https://git.lysator.liu.se/nettle/nettle/-/merge_requests/54 > Tested on POWER7 machines in little-endian and big-endian modes. > > regards, > Mamone > > >> regards, >> Mamone >> >> The fat setup for ppc is intended to enable the crashing code path only >>> if the feature bits PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX are >>> both set in the status word returned from >>> >>> hwcap = getauxval(AT_HWCAP); >>> >>> This logic is in >>> https://git.lysator.liu.se/nettle/nettle/-/blob/master/fat-ppc.c#L151 >>> and used to selct chacha code here: >>> https://git.lysator.liu.se/nettle/nettle/-/blob/master/fat-ppc.c#L232 >>> >>> > lscpu(1) output: >>> > >>> > Architecture:ppc64 >>> > CPU op-mode(s):32-bit, 64-bit >>> > Byte Order:Big Endian >>> > CPU(s): 4 >>> > On-line CPU(s) list: 0-3 >>> > Model name: POWER7 (architected), altivec supported >>> >>> Would you expect to have the "vsx" feature mentioned there or not? >>> >>> You can get some diagnostics from the initialization process by setting >>> the NETTLE_FAT_VERBOSE environment variable, and override the automatic >>> detection with the NETTLE_FAT_OVERRIDE environment variable. >>> >>> Can you check what getauxval(AT_HWCAP) returns on your system? >>> >>> I'm not so familiar with powerpc variants. Cc:ing Maamoun who's more >>> familiar with this arch. >>> >>> > Model: 2.3 (pvr 003f 0203) >>> > Thread(s) per core:4 >>> > Core(s) per socket:1 >>> > Socket(s): 1 >>> > Virtualization features: >>> > Hypervisor vendor: pHyp >>> > Virtualization type: para >>> >>> Is the program that crashes running under a vm, or is the kernel running >>> on the bare metal? Each layer of vm tends to be ian opportunity to >>> introduce >>> errors in the list of available processor features. >>> >>> > Caches (sum of all): >>> > L1d: 32 KiB (1 instance) >>> > L1i: 32 KiB (1 instance) >>> > L2:256 KiB (1 instance) >>> > L3:4 MiB (1 instance) >>> > NUMA: >>> > NUMA node(s): 2 >>> > NUMA node0 CPU(s): >>> > NUMA node1 CPU(s): 0-3 >>> > >>> > >>> > -- System Information: >>> > Debian Release: bookworm/sid >>> > APT prefers unstable >>> > APT policy: (500, 'unstable') >>> > merged-usr: no >>> > Architecture: ppc64 >>> > Foreign Architectures: powerpc >>> > >>> > Kernel: Linux 4.1.42-rivoreo-powerpc64-largepage (SMP w/4 CPU threads) >>> > Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), >>> LANGUAGE=zh_TW:zh_CN:zh:en_GB:en >>> > Shell: /bin/sh linked to /bin/dash >>> > Init: systemd (via /run/systemd/system) >>> > >>> > Versions of packages libnettle8 depends on: >>> > ii libc6 2.35-3 >>> > >>> > libnettle8 recommends no packages. >>> > >>> > libnettle8 suggests no packages. >>> > >>> > -- no debconf information >>> > >>> >>> Regards, >>> /Niels >>> >>> -- >>> Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. >>> Internet email is subject to wholesale government surveillance. >>> >> >
Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
Yes, I has already confirmed the fix in my last email. But it isn't automatically being CCed to Debian BTS for some reason. > -- Forwarded message -- > From: 王昊然 > Date: Fri, 21 Oct 2022 14:09:33 +0800 > Subject: Re: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7 > To: Maamoun TK > Cc: Niels Möller > > I can confirm this patch worked on my system. 2022-10-21 14:39 GMT+08:00, Niels Möller : > 王昊然 writes: > >> I have just installed a new Linux image with CONFIG_VSX=y, however nettle >> is >> still triggering illegal instruction there. > > I've now realized that the vmrgow instruction indeed is invalid on > power7, regardless of extensions (it's listed in the spec as added in > ISA v2.07, and power7 corresponds to v2.06, if I've understood it > correctly). Maamoun fixed it with > https://git.lysator.liu.se/nettle/nettle/-/merge_requests/54 > > Can you check if that solves the problem for you? It might be a > candidate for backporting into the debian package (there's no solid plan > for next Nettle release, but if there will be any 3.8.1 bugfix release, > this fix should be included). > > Regards, > /Niels > > -- > Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. > Internet email is subject to wholesale government surveillance. >
Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
王昊然 writes: > I have just installed a new Linux image with CONFIG_VSX=y, however nettle is > still triggering illegal instruction there. I've now realized that the vmrgow instruction indeed is invalid on power7, regardless of extensions (it's listed in the spec as added in ISA v2.07, and power7 corresponds to v2.06, if I've understood it correctly). Maamoun fixed it with https://git.lysator.liu.se/nettle/nettle/-/merge_requests/54 Can you check if that solves the problem for you? It might be a candidate for backporting into the debian package (there's no solid plan for next Nettle release, but if there will be any 3.8.1 bugfix release, this fix should be included). Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
Hello.
I have just installed a new Linux image with CONFIG_VSX=y, however nettle is
still triggering illegal instruction there.
2022-10-20 2:14 GMT+08:00, Niels Möller :
> 王昊然 writes:
>
>>> int main() {
>>> unsigned long int hwcap = getauxval(AT_HWCAP);
>>> printf("hwcap = 0x%lx\n", hwcap);
>>> return 0;
>>> }
>>> whr@debian:~/src$ gcc -Wall cpu-feature-test.c
>>> whr@debian:~/src$ ./a.out
>>> hwcap = 0xdc0065c2
>
> And the flags checked by nettle are (from
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/uapi/asm/cputable.h?h=v6.1-rc1)
>
>
> #define PPC_FEATURE_HAS_ALTIVEC 0x1000
> #define PPC_FEATURE_HAS_VSX 0x0080
>
> so both set in your case.
>
>>>
Is the program that crashes running under a vm, or is the kernel
running
on the bare metal? Each layer of vm tends to be ian opportunity to
introduce
errors in the list of available processor features.
>>>
>>> Operating systems on this machine are always running on the Power
>>> Hypervisor,
>>> which is a part of the server firmware.
>>>
>>
>> I just checked the nettle source code, it is indeed correctly checked
>> both
>> PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX; and with my HWCAP has
>> PPC_FEATURE_HAS_VSX set, I think it hits a limitation of this processor
>> feature checking logic: hardware supporting it, but the kernel didn't.
>>
>> I will try to build a new kernel with CONFIG_VSX enabled by tomorrow.
>
> My understanding is that AT_HWCAP should describe what instructions are
> available to userspace processes. If an instruction set extension isn't
> fully supported and enabled by all of hw/kernel/hypervisor, it should
> not be listed in hwcap. So the alternative might be to leave VSX
> disabled, but ensure it isn't advertised in hwcaps.
>
> Regards,
> /Niels
>
> --
> Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
> Internet email is subject to wholesale government surveillance.
>
Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
王昊然 writes:
>> int main() {
>> unsigned long int hwcap = getauxval(AT_HWCAP);
>> printf("hwcap = 0x%lx\n", hwcap);
>> return 0;
>> }
>> whr@debian:~/src$ gcc -Wall cpu-feature-test.c
>> whr@debian:~/src$ ./a.out
>> hwcap = 0xdc0065c2
And the flags checked by nettle are (from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/uapi/asm/cputable.h?h=v6.1-rc1)
#define PPC_FEATURE_HAS_ALTIVEC 0x1000
#define PPC_FEATURE_HAS_VSX 0x0080
so both set in your case.
>>
>>> Is the program that crashes running under a vm, or is the kernel running
>>> on the bare metal? Each layer of vm tends to be ian opportunity to
>>> introduce
>>> errors in the list of available processor features.
>>
>> Operating systems on this machine are always running on the Power
>> Hypervisor,
>> which is a part of the server firmware.
>>
>
> I just checked the nettle source code, it is indeed correctly checked both
> PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX; and with my HWCAP has
> PPC_FEATURE_HAS_VSX set, I think it hits a limitation of this processor
> feature checking logic: hardware supporting it, but the kernel didn't.
>
> I will try to build a new kernel with CONFIG_VSX enabled by tomorrow.
My understanding is that AT_HWCAP should describe what instructions are
available to userspace processes. If an instruction set extension isn't
fully supported and enabled by all of hw/kernel/hypervisor, it should
not be listed in hwcap. So the alternative might be to leave VSX
disabled, but ensure it isn't advertised in hwcaps.
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
-- Forwarded message --
From: 王昊然
Date: Thu, 20 Oct 2022 00:33:18 +0800
Subject: Re: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
To: Niels Möller
2022-10-20 0:18 GMT+08:00, 王昊然 :
>> The ppc specification says "vmrgow is treated as a Vector
>> instruction in terms of resource availability.", it's not entirely clear
>> to me what that means, and if checking for altivec support should be
>> enough.
>>
>> The fat setup for ppc is intended to enable the crashing code path only
>> if the feature bits PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX are
>> both set in the status word returned from
>> ...
>
> Thanks for the hint, I guess this issue is likely caused by my kernel which
> wasn't have CONFIG_VSX enabled. But in my understanding, this feature is an
> extension to AltiVec, not the AltiVec itself, so nettle shouldn't assume
> VSX
> to be available if they seen AltiVec available.
>
>
>> You can get some diagnostics from the initialization process by setting
>> the NETTLE_FAT_VERBOSE environment variable, and override the automatic
>> detection with the NETTLE_FAT_OVERRIDE environment variable.
>
> $ NETTLE_FAT_VERBOSE=1 test-program
> libnettle: cpu features:
> libnettle: enabling altivec code.
> Illegal instruction
>
>
>> Can you check what getauxval(AT_HWCAP) returns on your system?
>
> whr@debian:~/src$ cat cpu-feature-test.c
> #include
> #include
>
> int main() {
> unsigned long int hwcap = getauxval(AT_HWCAP);
> printf("hwcap = 0x%lx\n", hwcap);
> return 0;
> }
> whr@debian:~/src$ gcc -Wall cpu-feature-test.c
> whr@debian:~/src$ ./a.out
> hwcap = 0xdc0065c2
>
>
>> Is the program that crashes running under a vm, or is the kernel running
>> on the bare metal? Each layer of vm tends to be ian opportunity to
>> introduce
>> errors in the list of available processor features.
>
> Operating systems on this machine are always running on the Power
> Hypervisor,
> which is a part of the server firmware.
>
I just checked the nettle source code, it is indeed correctly checked both
PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX; and with my HWCAP has
PPC_FEATURE_HAS_VSX set, I think it hits a limitation of this processor
feature checking logic: hardware supporting it, but the kernel didn't.
I will try to build a new kernel with CONFIG_VSX enabled by tomorrow.
Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
-- Forwarded message --
From: 王昊然
Date: Thu, 20 Oct 2022 00:18:35 +0800
Subject: Re: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
To: Niels Möller
> The ppc specification says "vmrgow is treated as a Vector
> instruction in terms of resource availability.", it's not entirely clear
> to me what that means, and if checking for altivec support should be enough.
>
> The fat setup for ppc is intended to enable the crashing code path only
> if the feature bits PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX are
> both set in the status word returned from
> ...
Thanks for the hint, I guess this issue is likely caused by my kernel which
wasn't have CONFIG_VSX enabled. But in my understanding, this feature is an
extension to AltiVec, not the AltiVec itself, so nettle shouldn't assume VSX
to be available if they seen AltiVec available.
> You can get some diagnostics from the initialization process by setting
> the NETTLE_FAT_VERBOSE environment variable, and override the automatic
> detection with the NETTLE_FAT_OVERRIDE environment variable.
$ NETTLE_FAT_VERBOSE=1 test-program
libnettle: cpu features:
libnettle: enabling altivec code.
Illegal instruction
> Can you check what getauxval(AT_HWCAP) returns on your system?
whr@debian:~/src$ cat cpu-feature-test.c
#include
#include
int main() {
unsigned long int hwcap = getauxval(AT_HWCAP);
printf("hwcap = 0x%lx\n", hwcap);
return 0;
}
whr@debian:~/src$ gcc -Wall cpu-feature-test.c
whr@debian:~/src$ ./a.out
hwcap = 0xdc0065c2
> Is the program that crashes running under a vm, or is the kernel running
> on the bare metal? Each layer of vm tends to be ian opportunity to introduce
> errors in the list of available processor features.
Operating systems on this machine are always running on the Power Hypervisor,
which is a part of the server firmware.
