Re: bin/53532: ftp(1) dumps core while trying to download via HTTP with the auto-fetch feature

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

The following reply was made to PR bin/53532; it has been noted by GNATS.

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/53532: ftp(1) dumps core while trying to download via HTTP
 with the auto-fetch feature
Date: Fri, 17 Aug 2018 11:10:00 -0400

 On Fri, 2018-08-17 at 07:00 +0000, Martin Husemann wrote:
 > The following reply was made to PR bin/53532; it has been noted by
 > GNATS.
 > 
 > From: Martin Husemann <martin%duskware.de@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: bin/53532: ftp(1) dumps core while trying to download via
 > HTTP
 >  with the auto-fetch feature
 > Date: Fri, 17 Aug 2018 08:59:00 +0200
 > 
 >  I can not reproduce it. Can you make a core dump available, or do
 > something
 >  like
 >  
 >    x/i $pc
 >  
 >  to see what instruction it faults on? My guess would be: some SSE
 >  instruction used in openssl - which is supposed to auto-detect the
 >  available instructions at run time, but may have a bug for your CPU.
 >  
 >  Can you also provide output of "cpuctl identify 0"?
 >  
 >  Thanks,
 >  
 >  Martin
 
 Hi Martin,
 
 If I understand correctly, the issue is that there are/were mismatches
 in NetBSD's build configuration for OpenSSL that caused the generated
 assembly for some functions to be out of sync with the runtime check
 it uses to detect CPU capabilities.
 
 The gcm_ghash_4bit_mmx function in NetBSD's generated version of
 ghash-x86.S uses the pinsrw instruction, which is not part of MMX.
 Separately, gcm128.c has the following:
 
 #   if  defined(OPENSSL_IA32_SSE2)
     if (OPENSSL_ia32cap_P[0] & (1 << 25)) { /* check SSE bit */
 #   else
     if (OPENSSL_ia32cap_P[0] & (1 << 23)) { /* check MMX bit */
 #   endif
         ctx->gmult = gcm_gmult_4bit_mmx;
         ctx->ghash = gcm_ghash_4bit_mmx;
     } else {
         ctx->gmult = gcm_gmult_4bit_x86;
         ctx->ghash = gcm_ghash_4bit_x86;
     }
 
 So we can end up with a gcm_gmult_4bit_mmx implementation that
 expects pinsrw to be available, but have a runtime check that looks
 at the MMX bit, rather than the SSE bit, which is what I assume is
 happening in my case.
 
 A change christos@ made to HEAD on August 1st (that I referenced in
 a previous update to this ticket) is meant to address this
 discrepancy, I believe, by more broadly defining OPENSSL_IA32_SSE2.
 I don't know whether it addresses my issue specifically, as I haven't
 had a chance to test it against netbsd-8.
 
 (I'd sent the output of "cpuctl identify 0" in a previous update to
 this ticket as well: it's a Pentium II, so it has MMX but no SSE.)
 
 Regards,
 
 Dave