Date: Sat, 4 Mar 2017 16:35:54 -0800 From: Mark Millard <markmi@dsl-only.net> To: Andrew Gierth <andrew@tao11.riddles.org.uk> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <9677298B-5A5E-44BF-928E-28DDDADB310A@dsl-only.net> In-Reply-To: <87lgsk1udz.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <CANCZdfq4EwH%2B_9FVNai8s6Y-gdTjHJ8dNkJwSrnF%2BSAkdwvYdg@mail.gmail.com> <87tw7820fc.fsf@news-spur.riddles.org.uk> <644D1F49-BF5D-409D-BFC4-4F7E6E73085B@dsl-only.net> <87lgsk1udz.fsf@news-spur.riddles.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Mar-4, at 4:02 PM, Andrew Gierth <andrew at =
tao11.riddles.org.uk> wrote:
>>>>>> "Mark" =3D=3D Mark Millard <markmi@dsl-only.net> writes:
>=20
> Mark> Trying (1) on a bpim3 with head instead (still clang 3.9.1
> Mark> based), I get such notices for:
>=20
> Mark> Doing 512 bit public rsa's for 10s: RSA verify failure
> Mark> Doing 2048 bit public rsa's for 10s: RSA verify failure
> Mark> Doing 4096 bit public rsa's for 10s: RSA verify failure
>=20
> Mark> I also get:
>=20
> Mark> Doing 512 bit sign dsa's for 10s: 10527 512 bit DSA signs in =
10.09s
> Mark> DSA verify failure. No DSA verify will be done.
> Mark> Doing 1024 bit sign dsa's for 10s: 4035 1024 bit DSA signs in =
10.02s
> Mark> Doing 1024 bit verify dsa's for 10s: DSA verify failure
> Mark> 1 1024 bit DSA verify in 10.00s
> Mark> Doing 2048 bit sign dsa's for 10s: 1239 2048 bit DSA signs in =
10.07s
> Mark> DSA verify failure. No DSA verify will be done.
>=20
> Mark> Doing 409 bit verify ecdsa's for 10s: ECDSA verify failure
> Mark> 1 409 bit ECDSA verify in 10.02s
>=20
> Yes, that seems identical to what I got. Just to be clear: what =
compile
> options is that with?
I happened to have cross built amd64->bpim3.
# uname -paKU
FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r314479M arm armv6 =
1200022 1200022
(I'm in the middle of updating to a clang 4.0 based vintage
everywhere and the amd64 context has been updated for
/usr/src/ since the bpim3 build.)
# more ~/src.configs/make.conf
CFLAGS.gcc+=3D -v
(but no gcc was in use).
# more ~/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host=20
TO_TYPE=3Darmv6
#
KERNCONF=3DBPIM3-NODBG
TARGET=3Darm
.if ${.MAKE.LEVEL} =3D=3D 0
TARGET_ARCH=3D${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=3D
WITHOUT_SYSTEM_COMPILER=3D
#
WITH_LIBCPLUSPLUS=3D
WITH_BINUTILS_BOOTSTRAP=3D
WITH_ELFTOOLCHAIN_BOOTSTRAP=3D
WITH_CLANG_BOOTSTRAP=3D
WITH_CLANG=3D
WITH_CLANG_IS_CC=3D
WITH_CLANG_FULL=3D
WITH_CLANG_EXTRAS=3D
WITH_LLD=3D
#
# Linking lldb fails for armv6(/v7) (historical binutils)
WITHOUT_LLDB=3D
#
WITH_BOOT=3D
WITHOUT_LIB32=3D
WITHOUT_LIBSOFT=3D
#
WITHOUT_GCC_BOOTSTRAP=3D
WITHOUT_GCC=3D
WITHOUT_GCC_IS_CC=3D
WITHOUT_GNUCXX=3D
#
NO_WERROR=3D
#WERROR=3D
MALLOC_PRODUCTION=3D
#
WITH_REPRODUCIBLE_BUILD=3D
WITH_DEBUG_FILES=3D
#
XCFLAGS+=3D -mcpu=3Dcortex-a7
XCXXFLAGS+=3D -mcpu=3Dcortex-a7
# There is no XCPPFLAGS but XCPP gets XCFLAGS content.
# more /usr/src/sys/arm/conf/BPIM3-NODBG=20
#
# BPIM3 -- Custom configuration for the Banana Pi M3
#
include "GENERIC"
ident BPIM3-NODBG
makeoptions DEBUG=3D-g # Build kernel with gdb(1) =
debug symbols
options ALT_BREAK_TO_DEBUGGER
options KDB # Enable kernel debugger support
# For minimum debugger support (stable branch) use:
options KDB_TRACE # Print a stack trace for a =
panic
options DDB # Enable the kernel debugger
# Extra stuff:
#options VERBOSE_SYSINIT # Enable verbose sysinit =
messages
#options BOOTVERBOSE=3D1
#options BOOTHOWTO=3DRB_VERBOSE
#options KTR
#options KTR_MASK=3DKTR_TRAP
##options KTR_CPUMASK=3D0xF
#options KTR_VERBOSE
# Disable any extra checking for. . .
nooptions DEADLKRES # Enable the deadlock resolver
nooptions INVARIANTS # Enable calls of extra sanity =
checking
nooptions INVARIANT_SUPPORT # Extra sanity checks of =
internal structures, required by INVARIANTS
nooptions WITNESS # Enable checks to detect =
deadlocks and cycles
nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks =
for speed
nooptions DIAGNOSTIC
(/usr/src/ info below is from the bpim3 itself, not the amd64
cross build environment that is in the middle of an update
sequence. It should be accurate to what the build was based
on.)
# svnlite info /usr/src/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 314479
Last Changed Rev: 314479
# svnlite status /usr/src/ | sort
? /usr/src/sys/amd64/conf/GENERIC-DBG
? /usr/src/sys/amd64/conf/GENERIC-NODBG
? /usr/src/sys/arm/conf/BPIM3-DBG
? /usr/src/sys/arm/conf/BPIM3-NODBG
? /usr/src/sys/arm/conf/RPI2-DBG
? /usr/src/sys/arm/conf/RPI2-NODBG
? /usr/src/sys/arm64/conf/GENERIC-DBG
? /usr/src/sys/arm64/conf/GENERIC-NODBG
? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG
? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp
M /usr/src/lib/csu/powerpc64/Makefile
M /usr/src/libexec/rtld-elf/Makefile
M /usr/src/sys/boot/ofw/Makefile.inc
M /usr/src/sys/boot/powerpc/Makefile.inc
M /usr/src/sys/boot/powerpc/kboot/Makefile
M /usr/src/sys/boot/uboot/Makefile.inc
M /usr/src/sys/conf/kmod.mk
M /usr/src/sys/ddb/db_main.c
M /usr/src/sys/ddb/db_script.c
M /usr/src/sys/powerpc/ofw/ofw_machdep.c
> But I'm not convinced this is a problem in openssl (rather than
> somewhere else). Here's why:
>=20
> 1. When looking at git, I tried logging the input and output of all =
the
> SHA1 calls, and replaying them through a test program that called the
> same openssl functions on the same data (with the same alignment); the
> test program always got the correct hashes, even for cases where the
> logged data showed that the hash had been computed incorrectly
>=20
> 2. Running openssl speed under gdb with a conditional breakpoint set =
to
> look for padding failures stops the error from occurring at all (!).
>=20
> 3. The errors aren't consistent at all. For example, sometimes I run
> openssl speed rsa512 and it succeeds without error. When testing with
> git, the failures were not always at the same place.
Interesting. My context had MALLOC_PRODUCTION. I wonder if without that
and having junk filled in systematically might produce more stable
results. (I've no specific evidence that this would make a difference.)
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9677298B-5A5E-44BF-928E-28DDDADB310A>