daily CVS update output
Updating src tree: P src/crypto/external/bsd/openssl/dist/crypto/modes/gcm128.c cvs update: `src/crypto/external/bsd/openssl/lib/libcrypto/arch/sparc/modes.inc' is no longer in the repository P src/distrib/sets/lists/comp/mi P src/distrib/sets/lists/tests/mi P src/doc/3RDPARTY P src/doc/CHANGES P src/etc/protocols P src/etc/services P src/external/bsd/elftoolchain/dist/common/elfdefinitions.h P src/lib/Makefile P src/libexec/httpd/bozohttpd.c P src/libexec/httpd/cgi-bozo.c P src/libexec/httpd/small/Makefile P src/sys/dev/mca/if_we_mca.c P src/sys/kern/kern_tc.c P src/tests/usr.bin/xlint/check-expect.lua P src/tests/usr.bin/xlint/lint1/Makefile U src/tests/usr.bin/xlint/lint1/feat_stacktrace.c U src/tests/usr.bin/xlint/lint1/feat_stacktrace.exp P src/tests/usr.bin/xlint/lint1/msg_247.c P src/tests/usr.bin/xlint/lint1/msg_247.exp P src/tests/usr.bin/xlint/lint1/t_integration.sh P src/usr.bin/xlint/lint1/err.c P src/usr.bin/xlint/lint1/externs1.h P src/usr.bin/xlint/lint1/lex.c P src/usr.bin/xlint/lint1/tree.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 41152479 Apr 9 03:03 ls-lRA.gz
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
On Thu, 8 Apr 2021, Martin Husemann wrote: > This has now been fixed in -current and already been pulled up to netbsd-9. I've now updated a test system with the latest netbsd-9/sparc and the simplified test case works. It does still probe the several sparcv9 instructions, but after continuing through those, it goes ahead. While writing this, the conditions needed for me to update the mail hub machine were met. This will be the first message through it. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
hello John. Just for completeness, and perhaps I'm mistaken, but it looks like your new setup isn't actually using tls in its smtp transactions at the moment, see below. Since I'm not familir with your setup, I could be completely mistaken, but I note it here in case you want to verify that it's working. -thanks -Brian --- Forwarded mail from "John D. Baker" Received: from mail238c25.carrierzone.com (mail448c25.carrierzone.com [209.235.146.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3ED3484C86; Thu, 8 Apr 2021 23:02:18 + (UTC) X-Authenticated-User: jdba...@consolidated.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=carrierzone.com; s=mailmia; t=1617921724; bh=6XzMGbgl7szZ3CIWi7d5kU2vpW5Rc8K2pQGJ9P7D+4Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sxU6yJLo+boAQ9PI6eYOx6aBgVk6/nBgyGBwURw49jF8rOdHyk1nlOP3YXrDRstsM TQXuA37waCc+XmDQDZ+z2zKpH1ltCn8267DeeYM/+o7RJ77Fon1X9rz2ktk9KHjjvk XfawamtZ5KKPwsNF9nwT7Qpnduj0I1M1yg1x9Hps= Feedback-ID:jdbaker@consoli Received: from david.technoskunk.fur (dsl-dhcp-katytxxchrc-64-92-10-42.consolidated.net [64.92.10.42]) (authenticated bits=0) by mail238c25.carrierzone.com (8.14.9/8.13.1) with ESMTP id 138MfvHE018238; Thu, 8 Apr 2021 22:42:03 +
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
On Thu, 8 Apr 2021, Martin Husemann wrote:
> This has now been fixed in -current and already been pulled up to netbsd-9.
Looking at my rolled-back OpenSSL in my test netbsd-9 tree, the old
"crypto/external/bsd/openssl/lib/libcrypto/arch/sparc/modes.inc" file
conditionalized the assembly files/flags:
.if ${MACHINE} == "sparc64"
.PATH.S: ${.PARSEDIR}
MODES_SRCS = ghash-sparcv9.S
MODESCPPFLAGS = -DGHASH_ASM
AFLAGS.ghash-sparcv9.S+= -Wa,-Av9
.endif
.include "../../modes.inc"
But since the machine in question is "sparc" and there is a separate
"arch/sparc64", the file would be unnecessary for "sparc".
> Thanks for the report!
Thanks for getting it sorted out.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
On Thu, 8 Apr 2021, Christos Zoulas wrote: > Well, the assembly block is enabled only if we have vis3 instructions: > What does OPENSSL_sparcv9_cap_P[0] contain. I see this has already been analyzed, but, following Martin's example for the simple test case, I get (gdb) p OPENSSL_sparcv9cap_P[0] $1 = 2 (gdb) p OPENSSL_sparcv9cap_P[1] $2 = 0 after the SIGILL in gcm_ghash_4bit() on a -current sparc system from about 3 April 2021. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
This has now been fixed in -current and already been pulled up to netbsd-9. Thanks for the report! Martin
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2021.04.08.12.31.49 christos src/crypto/external/bsd/openssl/dist/crypto/modes/gcm128.c,v 1.12 2021.04.08.13.04.01 martin src/distrib/sets/lists/comp/mi,v 1.2378 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2021.04.html#2021.04.08.13.04.01
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
On Thu, 8 Apr 2021, RVP wrote: > As a workaround, until the offending opcode is found, try > `#undef GHASH_ASM_SPARC' on line 692 in > src/crypto/external/bsd/openssl/dist/crypto/modes/gcm128.c to force > use of the C functions. A diff of "gcm128c" between -current and netbsd-9 before the pullup shows: [...] -# if defined(__arch64__) -# define GHASH_ASM_SPARC -# define GCM_FUNCREF_4BIT +# define GHASH_ASM_SPARC +# define GCM_FUNCREF_4BIT extern unsigned int OPENSSL_sparcv9cap_P[]; void gcm_init_vis3(u128 Htable[16], const u64 Xi[2]); void gcm_gmult_vis3(u64 Xi[2], const u128 Htable[16]); void gcm_ghash_vis3(u64 Xi[2], const u128 Htable[16], const u8 *inp, size_t len); -# endif [...] That is, before the pull-up of OpenSSL 1.1.1k, the "GHASH_ASM_SPARC" macro was conditionally defined iff "__arch64__" was also defined-- likely an internal compiler definition. With -current and netbsd-9 after the pull up, that conditionalization has been removed. The supplied assembly code (wrapped in a perl script) implies by filename that it is for sparcv9 and up CPUs. Alas I don't know sparc assembly, so I will have to defer to others whether it can be rendered harmless for sparcv8 and prior CPUs. Or just reinstate the above conditionalization. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
In article <1923806e-bdd4-4c7e-9b07-d8937320f...@zoulas.com>,
Christos Zoulas wrote:
>-=-=-=-=-=-
>
>Well, the assembly block is enabled only if we have vis3 instructions:
>
># elif defined(GHASH_ASM_SPARC)
>if (OPENSSL_sparcv9cap_P[0] & SPARCV9_VIS3) {
>gcm_init_vis3(ctx->Htable, ctx->H.u);
>ctx->gmult = gcm_gmult_vis3;
>CTX__GHASH(gcm_ghash_vis3);
>} else {
>gcm_init_4bit(ctx->Htable, ctx->H.u);
>ctx->gmult = gcm_gmult_4bit;
>CTX__GHASH(gcm_ghash_4bit);
>}
>
>What does OPENSSL_sparcv9_cap_P[0] contain.
We are dying in gcm_gmult_4bit because it uses ldx/stx which is only
available on v9... So yes, I have disabled the sparc assembly completely
again as before with __arch64__
christos
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
Well, the assembly block is enabled only if we have vis3 instructions:
# elif defined(GHASH_ASM_SPARC)
if (OPENSSL_sparcv9cap_P[0] & SPARCV9_VIS3) {
gcm_init_vis3(ctx->Htable, ctx->H.u);
ctx->gmult = gcm_gmult_vis3;
CTX__GHASH(gcm_ghash_vis3);
} else {
gcm_init_4bit(ctx->Htable, ctx->H.u);
ctx->gmult = gcm_gmult_4bit;
CTX__GHASH(gcm_ghash_4bit);
}
What does OPENSSL_sparcv9_cap_P[0] contain.
christos
> On Apr 8, 2021, at 7:04 AM, Martin Husemann wrote:
>
> On Thu, Apr 08, 2021 at 02:36:07AM -0500, John D. Baker wrote:
>> -# if defined(__arch64__)
>> -# define GHASH_ASM_SPARC
>> -# define GCM_FUNCREF_4BIT
>> +# define GHASH_ASM_SPARC
>> +# define GCM_FUNCREF_4BIT
>> extern unsigned int OPENSSL_sparcv9cap_P[];
>> void gcm_init_vis3(u128 Htable[16], const u64 Xi[2]);
>> void gcm_gmult_vis3(u64 Xi[2], const u128 Htable[16]);
>> void gcm_ghash_vis3(u64 Xi[2], const u128 Htable[16], const u8 *inp,
>> size_t len);
>> -# endif
>> [...]
>>
>> That is, before the pull-up of OpenSSL 1.1.1k, the "GHASH_ASM_SPARC"
>> macro was conditionally defined iff "__arch64__" was also defined--
>> likely an internal compiler definition.
>
> I had a look and can reproduce the issue localy (without sendmail
> involved) - a simple:
>
> openssl s_client -starttls smtp -connect ${MAIL_SERVER}:25
>
> does it.
>
> Different to other asm code that e.g. properly detetects various VIS
> instructions that may or may not be available on the current CPU, the code
> in ghash-sparcv9.pl is plain sparcv9 code and can not be enabled for our
> sparc builds.
>
> Christos, can you disable all "modes" asm and request pullup?
> I can quickly test on -current...
>
> Martin
signature.asc
Description: Message signed with OpenPGP
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
Trying again as the original seems to have disappeared... On Thu, 8 Apr 2021, John D. Baker wrote: > Date: Thu, 8 Apr 2021 02:36:07 -0500 (CDT) > From: John D. Baker > To: RVP > Cc: Martin Husemann , John Nemeth , > current-users@NetBSD.org > Subject: Re: mail/sendmail not relaying on netbsd-9/sparc, > problem with OpenSSL update? > > On Thu, 8 Apr 2021, RVP wrote: > > > As a workaround, until the offending opcode is found, try > > `#undef GHASH_ASM_SPARC' on line 692 in > > src/crypto/external/bsd/openssl/dist/crypto/modes/gcm128.c to force > > use of the C functions. > > A diff of "gcm128c" between -current and netbsd-9 before the pullup > shows: > > [...] > -# if defined(__arch64__) > -# define GHASH_ASM_SPARC > -# define GCM_FUNCREF_4BIT > +# define GHASH_ASM_SPARC > +# define GCM_FUNCREF_4BIT > extern unsigned int OPENSSL_sparcv9cap_P[]; > void gcm_init_vis3(u128 Htable[16], const u64 Xi[2]); > void gcm_gmult_vis3(u64 Xi[2], const u128 Htable[16]); > void gcm_ghash_vis3(u64 Xi[2], const u128 Htable[16], const u8 *inp, > size_t len); > -# endif > [...] > > That is, before the pull-up of OpenSSL 1.1.1k, the "GHASH_ASM_SPARC" > macro was conditionally defined iff "__arch64__" was also defined-- > likely an internal compiler definition. > > With -current and netbsd-9 after the pull up, that conditionalization > has been removed. The supplied assembly code (wrapped in a perl > script) implies by filename that it is for sparcv9 and up CPUs. > > Alas I don't know sparc assembly, so I will have to defer to others > whether it can be rendered harmless for sparcv8 and prior CPUs. > > Or just reinstate the above conditionalization. > > -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
On Thu, Apr 08, 2021 at 02:36:07AM -0500, John D. Baker wrote:
> -# if defined(__arch64__)
> -# define GHASH_ASM_SPARC
> -# define GCM_FUNCREF_4BIT
> +# define GHASH_ASM_SPARC
> +# define GCM_FUNCREF_4BIT
> extern unsigned int OPENSSL_sparcv9cap_P[];
> void gcm_init_vis3(u128 Htable[16], const u64 Xi[2]);
> void gcm_gmult_vis3(u64 Xi[2], const u128 Htable[16]);
> void gcm_ghash_vis3(u64 Xi[2], const u128 Htable[16], const u8 *inp,
> size_t len);
> -# endif
> [...]
>
> That is, before the pull-up of OpenSSL 1.1.1k, the "GHASH_ASM_SPARC"
> macro was conditionally defined iff "__arch64__" was also defined--
> likely an internal compiler definition.
I had a look and can reproduce the issue localy (without sendmail
involved) - a simple:
openssl s_client -starttls smtp -connect ${MAIL_SERVER}:25
does it.
Different to other asm code that e.g. properly detetects various VIS
instructions that may or may not be available on the current CPU, the code
in ghash-sparcv9.pl is plain sparcv9 code and can not be enabled for our
sparc builds.
Christos, can you disable all "modes" asm and request pullup?
I can quickly test on -current...
Martin
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
On Wed, 7 Apr 2021, John D. Baker wrote: and one more __sigaction_sigtramp(SIGILL...) Then, at the end: PSIG SIGILL SIG_DFL: code=ILL_ILLOPC, addr=0xedccbdf0, trap=2) Program was terminated due to an illegal opcode being detected in the gcm_ghash_4bit() assembly function: Program received signal SIGILL, Illegal instruction. 0xedccbdf0 in gcm_ghash_4bit () from /usr/lib/libcrypto.so.14 (gdb) bt #0 0xedccbdf0 in gcm_ghash_4bit () from /usr/lib/libcrypto.so.14 (gdb) As a workaround, until the offending opcode is found, try `#undef GHASH_ASM_SPARC' on line 692 in src/crypto/external/bsd/openssl/dist/crypto/modes/gcm128.c to force use of the C functions. -RVP
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2021.04.08.08.10.30. An extract from the build.sh output follows: --- checkflist --- cd /tmp/build/2021.04.08.08.10.30-i386/src/distrib/sets && DESTDIR=/tmp/build/2021.04.08.08.10.30-i386/destdir MACHINE=i386 MACHINE_ARCH=i386 AWK=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbawk CKSUM=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbcksum DB=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbdb EGREP=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbgrep\ -E HOST_SH=/bin/sh MAKE=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbmake MKTEMP=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbmktemp MTREE=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbmtree PAX=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbpax COMPRESS_PROGRAM=gzip GZIP=-n XZ_OPT=-9 TAR_SUFF=tgz PKG_CREATE=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbpkg_create SED=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbsed TSORT=/tmp/build/2021.04.08.08.10.30-i386/tools/bin/nbtsort\ -q /bin/sh /tmp/build/2021.04.08.08.10.30-i386/src/distrib/sets/checkflist -L base -M /tmp/build/2021.04. 08.08.10.30-i386/destdir/METALOG.sanitised === 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/include/elfdefinitions.h ./usr/include/sys/elfdefinitions.h = end of 2 extra files === *** [checkflist] Error code 1 nbmake[2]: stopped in /tmp/build/2021.04.08.08.10.30-i386/src/distrib/sets 1 error nbmake[2]: stopped in /tmp/build/2021.04.08.08.10.30-i386/src/distrib/sets nbmake[1]: stopped in /tmp/build/2021.04.08.08.10.30-i386/src nbmake: stopped in /tmp/build/2021.04.08.08.10.30-i386/src ERROR: Failed to make release The following commits were made between the last successful build and the failed build: 2021.04.08.08.10.30 jkoshy src/lib/Makefile,v 1.290 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2021.04.html#2021.04.08.08.10.30
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
On Thu, Apr 08, 2021 at 02:36:07AM -0500, John D. Baker wrote: > That is, before the pull-up of OpenSSL 1.1.1k, the "GHASH_ASM_SPARC" > macro was conditionally defined iff "__arch64__" was also defined-- > likely an internal compiler definition. > > With -current and netbsd-9 after the pull up, that conditionalization > has been removed. The supplied assembly code (wrapped in a perl > script) implies by filename that it is for sparcv9 and up CPUs. Yes. Previously the probe (and usage) of this instructions was restricted to running sparc64. However, this is wrong, as we can run sparc userland on CPUs that have these instructions, so probing should be done there too. The probing needs to work correctly though, and something is wrong there. I'm investigating (should be pretty easy with only base system, no sendmail needed and concrete mail host needed). Martin
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
Trying this again since the first message seems to have disappeared. On Wed, 7 Apr 2021, John D. Baker wrote: > On Wed, 7 Apr 2021, John D. Baker wrote: > > > I'm updating my -current install and will try again from there and > > see what happens. > > Same as netbsd-9 with OpenSSL 1.1.1k. > > > $ sudo ktrace -i sendmail -odi -v -q > > Running /var/spool/mqueue/137HphNB000892 (sequence 1 of 1) > ... Connecting to mail.consolidated.net. port 587 > via relay... > 220 mail239c25.carrierzone.com ESMTP Sendmail 8.14.9 ready at Wed, 7 Apr 2021 > 17:52:43 + > >>> EHLO > 250-mail239c25.carrierzone.com Hello [], > pleased to meet you > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250-SIZE 52428800 > 250-DSN > 250-AUTH > 250-STARTTLS > 250-DELIVERBY > 250 HELP > >>> STARTTLS > 220 Ready to start TLS > Illegal instruction > > > OK, looking more carefully at the trace output, I see a > > __sigaction_sigtramp(SIGILL...) > > four instances of > > PSIG SIGILL caught handler=0xedd18c60 ... code=ILL_COPROC, > > and one more > > __sigaction_sigtramp(SIGILL...) > > Then, at the end: > > PSIG SIGILL SIG_DFL: code=ILL_ILLOPC, addr=0xedccbdf0, trap=2) > > > Under 'gdb' then: > > (gdb) run -odi -v -q > Starting program: /usr/sbin/sendmail -odi -v -q > process 1426 is executing new program: /usr/pkg/libexec/sendmail/sendmail > > Program received signal SIGILL, Illegal instruction. > 0xedd6eacc in _sparcv9_vis1_probe () from /usr/lib/libcrypto.so.14 > (gdb) continue > Continuing. > > Program received signal SIGILL, Illegal instruction. > 0xedd6eacc in _sparcv9_vis1_probe () from /usr/lib/libcrypto.so.14 > (gdb) continue > Continuing. > > Program received signal SIGILL, Illegal instruction. > 0xedd6eb58 in _sparcv9_fmadd_probe () from /usr/lib/libcrypto.so.14 > (gdb) continue > Continuing. > > Program received signal SIGILL, Illegal instruction. > 0xedd6eb58 in _sparcv9_fmadd_probe () from /usr/lib/libcrypto.so.14 > (gdb) continue > Continuing. > > Program received signal SIGILL, Illegal instruction. > 0xedd6eb74 in _sparcv9_vis3_probe () from /usr/lib/libcrypto.so.14 > (gdb) continue > Continuing. > > Program received signal SIGILL, Illegal instruction. > 0xedd6eb74 in _sparcv9_vis3_probe () from /usr/lib/libcrypto.so.14 > (gdb) continue > Continuing. > > Program received signal SIGILL, Illegal instruction. > 0xedd6eb80 in _sparcv9_fjaesx_probe () from /usr/lib/libcrypto.so.14 > (gdb) continue > Continuing. > > Program received signal SIGILL, Illegal instruction. > 0xedd6eb80 in _sparcv9_fjaesx_probe () from /usr/lib/libcrypto.so.14 > (gdb) continue > Continuing. > > Running /var/spool/mqueue/137HphNB000892 (sequence 1 of 1) > ... Connecting to mail.consolidated.net. port 587 > via relay... > 220 mail7c25.carrierzone.com ESMTP Sendmail 8.14.9 ready at Wed, 7 Apr 2021 > 18:08:57 + > >>> EHLO > 250-mail7c25.carrierzone.com Hello [], pleased > to meet you > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250-SIZE 52428800 > 250-DSN > 250-AUTH > 250-STARTTLS > 250-DELIVERBY > 250 HELP > >>> STARTTLS > 220 Ready to start TLS > > Program received signal SIGILL, Illegal instruction. > 0xedccbdf0 in gcm_ghash_4bit () from /usr/lib/libcrypto.so.14 > (gdb) bt > #0 0xedccbdf0 in gcm_ghash_4bit () from /usr/lib/libcrypto.so.14 > (gdb) > > > So, there it is. Trying to list the address above doesn't display > anything. Attempting to 'continue' exits the program. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
> >> and one more > >> > >> __sigaction_sigtramp(SIGILL...) > >> > >> Then, at the end: > >> > >> PSIG SIGILL SIG_DFL: code=ILL_ILLOPC, addr=0xedccbdf0, trap=2) > > Program was terminated due to an illegal opcode being detected in > the gcm_ghash_4bit() assembly function: yes. John, can you, from gdb, print the value of OPENSSL_sparcv9cap_P[0] and OPENSSL_sparcv9cap_P[1]. if 1<<6 is set in the first, then the vis3 path will be taken in gcm_ghash_4bit(). it seems that these caps are setup wrongly. you could try to instrument OPENSSL_cpuid_setup() in crypto/external/bsd/openssl/dist/crypto/sparcv9cap.c to print the various settigs. it seems that SPARCV9_VIS3 is set. note that there are two places it can be set, but the first one is only for _SVR4 so not used here. nothing here seems changed with the update. these values should all be zero for real sparc 32 bit hardware (they're the sparcv9 caps after all :) > As a workaround, until the offending opcode is found, try > `#undef GHASH_ASM_SPARC' on line 692 in > src/crypto/external/bsd/openssl/dist/crypto/modes/gcm128.c to force > use of the C functions. good idea. .mrg.
