NetBSD Problem Report #53532

From www@NetBSD.org  Fri Aug 17 01:43:36 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 1830F7A1E8
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 17 Aug 2018 01:43:36 +0000 (UTC)
Message-Id: <20180817014334.8A1957A26D@mollari.NetBSD.org>
Date: Fri, 17 Aug 2018 01:43:34 +0000 (UTC)
From: david@gutteridge.ca
Reply-To: david@gutteridge.ca
To: gnats-bugs@NetBSD.org
Subject: ftp(1) dumps core while trying to download via HTTP with the auto-fetch feature
X-Send-Pr-Version: www-1.0

>Number:         53532
>Category:       bin
>Synopsis:       ftp(1) dumps core while trying to download via HTTP with the auto-fetch feature
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 17 01:45:00 +0000 2018
>Closed-Date:    Tue Aug 28 07:41:12 +0000 2018
>Last-Modified:  Tue Aug 28 07:41:12 +0000 2018
>Originator:     David H. Gutteridge
>Release:        8.0_STABLE
>Organization:
>Environment:
NetBSD arcusii.nonus-porta.net 8.0_STABLE NetBSD 8.0_STABLE (GENERIC) #0: Fri Jul 27 10:55:40 UTC 2018  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC i386

>Description:
While trying to download various files via ftp(1)'s auto-fetch
feature, I've found it consistently segfaults immediately upon
execution.

A sample command that triggers the issue is:

ftp -4 https://cdn.netbsd.org:443/pub/NetBSD/NetBSD-8.0/images/NetBSD-8.0-i386.iso

This results in:

Illegal instruction (core dumped) 

This occurs consistently on the i386 port (at least, running
8.0_STABLE). I cannot duplicate the issue on amd64 8.0_STABLE or
8.99.22, nor can I duplicate it on Fedora Linux i386 using their
version of the program ("tnftp 20151004").

I haven't had any luck getting a useful stack trace. I have the debug
set installed, yet I still get:

Reading symbols from /usr/bin/ftp...Reading symbols from /usr/libdata/debug//usr/bin/ftp.debug...done.
done.
[New process 1]
Core was generated by `ftp'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0xbb92bd50 in ?? ()
(gdb) bt
#0  0xbb92bd50 in ?? ()
#1  0x70502000 in ?? ()
#2  0xc0e090b0 in ?? ()
#3  0x10304060 in ?? ()
#4  0xa080f0d0 in ?? ()
#5  0x00000000 in ?? ()

>How-To-Repeat:
As above.
>Fix:
Unknown.

I won't have any further time to look into this further in the next
two weeks, but can do so after then, if need be.

>Release-Note:

>Audit-Trail:
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/53532: ftp(1) dumps core while trying to download via HTTP
 with the auto-fetch feature
Date: Thu, 16 Aug 2018 22:20:58 -0400

 Somehow I managed to get gdb to give me a little more information on
 another attempt:

 (gdb) bt full
 #0  0xb9a09d50 in gcm_ghash_4bit_mmx () from /usr/lib/libcrypto.so.12
 No symbol table info available.
 #1  0x00000000 in ?? ()
 No symbol table info available.

 I see there's a reference to MMX. The machine in question is a rather
 old beast I dragged out to see if it still worked:

 cpu0: highest basic info 00000002
 cpu0: Intel Celeron (Covington) (686-class), 348.96 MHz
 cpu0: family 0x6 model 0x5 stepping 0x1 (id 0x651)
 cpu0: features
 0x183fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE>
 cpu0: features 0x183fbff<MCA,CMOV,PAT,PSE36,MMX,FXSR>
 cpu0: I-cache 16KB 32B/line 4-way, D-cache 16KB 32B/line 4-way
 cpu0: L2 cache 512KB 32B/line 4-way
 cpu0: ITLB 32 4KB entries 4-way, 2 4MB entries fully associative
 cpu0: DTLB 64 4KB entries 4-way, 8 4MB entries 4-way
 cpu0: Initial APIC ID 0
 cpu0: Cluster/Package ID 0
 cpu0: microcode version 0x40, platform ID 0

 Dave


From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@NetBSD.org
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 00:34:12 -0400

 On Thu, 2018-08-16 at 22:20 -0400, David H. Gutteridge wrote:
 > I see there's a reference to MMX. The machine in question is a rather
 > old beast I dragged out to see if it still worked:
 > 
 > cpu0: highest basic info 00000002
 > cpu0: Intel Celeron (Covington) (686-class), 348.96 MHz
 > cpu0: family 0x6 model 0x5 stepping 0x1 (id 0x651)
 > cpu0: features
 > 0x183fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE>
 > cpu0: features 0x183fbff<MCA,CMOV,PAT,PSE36,MMX,FXSR>
 > cpu0: I-cache 16KB 32B/line 4-way, D-cache 16KB 32B/line 4-way
 > cpu0: L2 cache 512KB 32B/line 4-way
 > cpu0: ITLB 32 4KB entries 4-way, 2 4MB entries fully associative
 > cpu0: DTLB 64 4KB entries 4-way, 8 4MB entries 4-way
 > cpu0: Initial APIC ID 0
 > cpu0: Cluster/Package ID 0
 > cpu0: microcode version 0x40, platform ID 0

 Hmm, yes, this is a hardware-specific issue. I can't reproduce this
 on 8.0_STABLE/i386 with a more recent AMD Athlon CPU. It seems as if
 libcrypto isn't playing nice with antediluvian CPUs that provide MMX.
 Whether anyone really cares about this, I don't know. Obviously not a
 burning issue.

 Dave


From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@NetBSD.org
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 01:00:19 -0400

 There appears to be some overlap with this commit:

 Module Name:    src
 Committed By:   christos
 Date:           Wed Aug  1 11:39:53 UTC 2018

 Modified Files:
         src/crypto/external/bsd/openssl/lib/libcrypto/arch/i386:
 modes.inc

 Log Message:
 Add missing defines:
 https://github.com/openssl/openssl/pull/6828
 When ghash-x86.S is generated with -DOPENSSL_IA32_SSE2 we need to
 compile
 gcm128.c with the same flags.
 Reported by manu@


 To generate a diff of this commit:
 cvs rdiff -u -r1.1 -r1.2 \
     src/crypto/external/bsd/openssl/lib/libcrypto/arch/i386/modes.inc

 This hasn't been pulled up into the netbsd-8 branch.

 Dave


From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
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

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@NetBSD.org
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>
 > To: gnats-bugs@NetBSD.org
 > 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


From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/53532: ftp(1) dumps core while trying to download via HTTP
 with the auto-fetch feature
Date: Mon, 27 Aug 2018 20:40:42 -0400

 Hello,

 Releng ticket #985 for netbsd-8 has resolved this issue, this ticket
 can be closed.

 Regards,

 Dave


State-Changed-From-To: open->closed
State-Changed-By: msaitoh@NetBSD.org
State-Changed-When: Tue, 28 Aug 2018 07:41:12 +0000
State-Changed-Why:
Reporter verified this problem was resolved.
Thanks.


>Unformatted:

Home	PR Database Search