* macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 @ 2021-01-26 16:32 Peter Maydell 2021-01-26 16:36 ` Daniel P. Berrangé 2021-02-02 5:46 ` 罗勇刚(Yonggang Luo) 0 siblings, 2 replies; 27+ messages in thread From: Peter Maydell @ 2021-01-26 16:32 UTC (permalink / raw) To: QEMU Developers; +Cc: Alexander Graf, Daniel P. Berrange My Big Sur/Apple Silicon system fails "make check" in test-crypto-tlscredsx509: MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} G_TEST_SRCDIR=/Users/pm215/qemu/tests G_TEST_BUILDDIR=/Users/pm215/qemu/build/all/tests tests/test-crypto-tlscredsx509 --tap -k ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590: Failed to sign certificate ASN1 parser: Value is not valid. ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is not valid. make: *** [run-test-70] Error 1 Does this failure ring any bells for anybody? Here's the crypto part of the meson-log: Crypto TLS priority: "NORMAL" GNUTLS support: YES libgcrypt: NO nettle: YES XTS: YES crypto afalg: NO rng-none: NO Linux keyring: NO thanks -- PMM ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-26 16:32 macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 Peter Maydell @ 2021-01-26 16:36 ` Daniel P. Berrangé 2021-01-26 16:41 ` Peter Maydell 2021-02-02 5:46 ` 罗勇刚(Yonggang Luo) 1 sibling, 1 reply; 27+ messages in thread From: Daniel P. Berrangé @ 2021-01-26 16:36 UTC (permalink / raw) To: Peter Maydell; +Cc: Alexander Graf, QEMU Developers On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote: > My Big Sur/Apple Silicon system fails "make check" in > test-crypto-tlscredsx509: > > MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} > G_TEST_SRCDIR=/Users/pm215/qemu/tests > G_TEST_BUILDDIR=/Users/pm215/qemu/build/all/tests > tests/test-crypto-tlscredsx509 --tap -k > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590: > Failed to sign certificate ASN1 parser: Value is not valid. > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to > sign certificate ASN1 parser: Value is not valid. > make: *** [run-test-70] Error 1 > > > Does this failure ring any bells for anybody? Not seen it before. Is this using a gnutls from homebrew, or one that apple ship themselves ? Any idea what version it is ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-26 16:36 ` Daniel P. Berrangé @ 2021-01-26 16:41 ` Peter Maydell 2021-01-27 12:17 ` Daniel P. Berrangé 0 siblings, 1 reply; 27+ messages in thread From: Peter Maydell @ 2021-01-26 16:41 UTC (permalink / raw) To: Daniel P. Berrangé; +Cc: Alexander Graf, QEMU Developers On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote: > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590: > > Failed to sign certificate ASN1 parser: Value is not valid. > > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to > > sign certificate ASN1 parser: Value is not valid. > > make: *** [run-test-70] Error 1 > > > > > > Does this failure ring any bells for anybody? > > Not seen it before. > > Is this using a gnutls from homebrew, or one that apple > ship themselves ? Any idea what version it is ? Homebrew gnutls, 3.6.15. thanks -- PMM ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-26 16:41 ` Peter Maydell @ 2021-01-27 12:17 ` Daniel P. Berrangé 2021-01-27 12:35 ` Christian Schoenebeck 2021-01-27 16:44 ` Stefan Weil 0 siblings, 2 replies; 27+ messages in thread From: Daniel P. Berrangé @ 2021-01-27 12:17 UTC (permalink / raw) To: Peter Maydell; +Cc: Alexander Graf, QEMU Developers On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote: > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote: > > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590: > > > Failed to sign certificate ASN1 parser: Value is not valid. > > > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to > > > sign certificate ASN1 parser: Value is not valid. > > > make: *** [run-test-70] Error 1 > > > > > > > > > Does this failure ring any bells for anybody? > > > > Not seen it before. > > > > Is this using a gnutls from homebrew, or one that apple > > ship themselves ? Any idea what version it is ? > > Homebrew gnutls, 3.6.15. On further investigation it seems the error comes from libtasn1, but unfortunately there are 100's of scenarios it could arise so difficult one to debug. In the test_tls_generate_cert method in QEMU tests/crypto-tls-x509-helpers.c There are conditional lines like if (req->country) { if (req->altname1) { ...etc... I guess one, or more of those, is writing data that libtasn1 is not happy with. Some one with easy access to this apple silicon will likely need to start by incrementally disabling each of those conditionals eg. if (req->country && 0) until we find out which one (might be more than one) make the Failed to sign certificate ASN1 parser: Value is not valid. error message go away. NB, once that ASN1 error goes away, the QEMU test suite will likely give its own error because the certs will no longer have the data it is expecting. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 12:17 ` Daniel P. Berrangé @ 2021-01-27 12:35 ` Christian Schoenebeck 2021-01-27 12:38 ` Daniel P. Berrangé 2021-01-27 16:44 ` Stefan Weil 1 sibling, 1 reply; 27+ messages in thread From: Christian Schoenebeck @ 2021-01-27 12:35 UTC (permalink / raw) To: qemu-devel, Daniel P. Berrangé; +Cc: Peter Maydell, Alexander Graf On Mittwoch, 27. Januar 2021 13:17:23 CET Daniel P. Berrangé wrote: > On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote: > > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> wrote: > > > On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote: > > > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590: > > > > Failed to sign certificate ASN1 parser: Value is not valid. > > > > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to > > > > sign certificate ASN1 parser: Value is not valid. > > > > make: *** [run-test-70] Error 1 > > > > > > > > > > > > Does this failure ring any bells for anybody? > > > > > > Not seen it before. > > > > > > Is this using a gnutls from homebrew, or one that apple > > > ship themselves ? Any idea what version it is ? > > > > Homebrew gnutls, 3.6.15. > > On further investigation it seems the error comes from libtasn1, > but unfortunately there are 100's of scenarios it could arise > so difficult one to debug. I haven't looked into the relevant code of this discussion, but is the failing code dealing with Apple certificates? Because Apple just announced a switch of one of their intermediate certificates, so just in case this might be related. Best regards, Christian Schoenebeck ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 12:35 ` Christian Schoenebeck @ 2021-01-27 12:38 ` Daniel P. Berrangé 0 siblings, 0 replies; 27+ messages in thread From: Daniel P. Berrangé @ 2021-01-27 12:38 UTC (permalink / raw) To: Christian Schoenebeck; +Cc: Peter Maydell, Alexander Graf, qemu-devel On Wed, Jan 27, 2021 at 01:35:37PM +0100, Christian Schoenebeck wrote: > On Mittwoch, 27. Januar 2021 13:17:23 CET Daniel P. Berrangé wrote: > > On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote: > > > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> > wrote: > > > > On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote: > > > > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590: > > > > > Failed to sign certificate ASN1 parser: Value is not valid. > > > > > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to > > > > > sign certificate ASN1 parser: Value is not valid. > > > > > make: *** [run-test-70] Error 1 > > > > > > > > > > > > > > > Does this failure ring any bells for anybody? > > > > > > > > Not seen it before. > > > > > > > > Is this using a gnutls from homebrew, or one that apple > > > > ship themselves ? Any idea what version it is ? > > > > > > Homebrew gnutls, 3.6.15. > > > > On further investigation it seems the error comes from libtasn1, > > but unfortunately there are 100's of scenarios it could arise > > so difficult one to debug. > > I haven't looked into the relevant code of this discussion, but is the failing > code dealing with Apple certificates? Because Apple just announced a switch of > one of their intermediate certificates, so just in case this might be related. It shouldn't be affected. The test suite is creating its own self-signed root CA, and cert tree under that, so everything should be self contained. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 12:17 ` Daniel P. Berrangé 2021-01-27 12:35 ` Christian Schoenebeck @ 2021-01-27 16:44 ` Stefan Weil 2021-01-27 16:53 ` Daniel P. Berrangé 1 sibling, 1 reply; 27+ messages in thread From: Stefan Weil @ 2021-01-27 16:44 UTC (permalink / raw) To: Daniel P. Berrangé, Peter Maydell; +Cc: Alexander Graf, QEMU Developers Am 27.01.21 um 13:17 schrieb Daniel P. Berrangé: > On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote: >> On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> wrote: >>> On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote: >>>> ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590: >>>> Failed to sign certificate ASN1 parser: Value is not valid. >>>> ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to >>>> sign certificate ASN1 parser: Value is not valid. >>>> make: *** [run-test-70] Error 1 >>>> >>>> >>>> Does this failure ring any bells for anybody? >>> Not seen it before. >>> >>> Is this using a gnutls from homebrew, or one that apple >>> ship themselves ? Any idea what version it is ? >> Homebrew gnutls, 3.6.15. > On further investigation it seems the error comes from libtasn1, > but unfortunately there are 100's of scenarios it could arise > so difficult one to debug. > > In the test_tls_generate_cert method in QEMU tests/crypto-tls-x509-helpers.c > > There are conditional lines like > > if (req->country) { > > if (req->altname1) { > ...etc... > > I guess one, or more of those, is writing data that libtasn1 is not happy > with. > > Some one with easy access to this apple silicon will likely need to start > by incrementally disabling each of those conditionals eg. if (req->country > && 0) > > until we find out which one (might be more than one) make the > > Failed to sign certificate ASN1 parser: Value is not valid. > > error message go away. NB, once that ASN1 error goes away, the QEMU test > suite will likely give its own error because the certs will no longer > have the data it is expecting. > > Regards, > Daniel I could debug into gnutls_x509_crt_sign2. gnutls_x509_crt_privkey_sign seems to fail. Disabling the conditionals mentioned above did not help. And I also have another problem when running "make check-tcg": % make check-tcg BUILD TCG tests for aarch64-softmmu BUILD aarch64-softmmu guest-tests with cc /qemu/tests/tcg/aarch64/system/boot.S:81:18: error: unexpected token in '.section' directive .section .rodata ^ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 16:44 ` Stefan Weil @ 2021-01-27 16:53 ` Daniel P. Berrangé 2021-01-27 17:05 ` Stefan Weil 0 siblings, 1 reply; 27+ messages in thread From: Daniel P. Berrangé @ 2021-01-27 16:53 UTC (permalink / raw) To: Stefan Weil; +Cc: Peter Maydell, Alexander Graf, QEMU Developers On Wed, Jan 27, 2021 at 05:44:59PM +0100, Stefan Weil wrote: > Am 27.01.21 um 13:17 schrieb Daniel P. Berrangé: > > > On Tue, Jan 26, 2021 at 04:41:13PM +0000, Peter Maydell wrote: > > > On Tue, 26 Jan 2021 at 16:37, Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > On Tue, Jan 26, 2021 at 04:32:08PM +0000, Peter Maydell wrote: > > > > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590: > > > > > Failed to sign certificate ASN1 parser: Value is not valid. > > > > > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to > > > > > sign certificate ASN1 parser: Value is not valid. > > > > > make: *** [run-test-70] Error 1 > > > > > > > > > > > > > > > Does this failure ring any bells for anybody? > > > > Not seen it before. > > > > > > > > Is this using a gnutls from homebrew, or one that apple > > > > ship themselves ? Any idea what version it is ? > > > Homebrew gnutls, 3.6.15. > > On further investigation it seems the error comes from libtasn1, > > but unfortunately there are 100's of scenarios it could arise > > so difficult one to debug. > > > > In the test_tls_generate_cert method in QEMU tests/crypto-tls-x509-helpers.c > > > > There are conditional lines like > > > > if (req->country) { > > > > if (req->altname1) { > > ...etc... > > > > I guess one, or more of those, is writing data that libtasn1 is not happy > > with. > > > > Some one with easy access to this apple silicon will likely need to start > > by incrementally disabling each of those conditionals eg. if (req->country > > && 0) > > > > until we find out which one (might be more than one) make the > > > > Failed to sign certificate ASN1 parser: Value is not valid. > > > > error message go away. NB, once that ASN1 error goes away, the QEMU test > > suite will likely give its own error because the certs will no longer > > have the data it is expecting. > > > > Regards, > > Daniel > > > I could debug into gnutls_x509_crt_sign2. gnutls_x509_crt_privkey_sign seems > to fail. > > Disabling the conditionals mentioned above did not help. In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS" line and then re-build and re-run the test case. There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign that might give us useful info. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 16:53 ` Daniel P. Berrangé @ 2021-01-27 17:05 ` Stefan Weil 2021-01-27 18:17 ` Daniel P. Berrangé 0 siblings, 1 reply; 27+ messages in thread From: Stefan Weil @ 2021-01-27 17:05 UTC (permalink / raw) To: Daniel P. Berrangé; +Cc: Peter Maydell, Alexander Graf, QEMU Developers Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé: > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS" > line and then re-build and re-run the test case. > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign > that might give us useful info. > > Regards, > Daniel % LANG=C.UTF-8 tests/test-crypto-tlscredsx509 # random seed: R02S9b95072a368ad370cdd4c780b8074596 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: common.c[_gnutls_x509_der_encode]:855 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152 Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is not valid. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 17:05 ` Stefan Weil @ 2021-01-27 18:17 ` Daniel P. Berrangé 2021-01-27 18:56 ` Stefan Weil 0 siblings, 1 reply; 27+ messages in thread From: Daniel P. Berrangé @ 2021-01-27 18:17 UTC (permalink / raw) To: Stefan Weil; +Cc: Peter Maydell, Alexander Graf, QEMU Developers On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote: > Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé: > > > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS" > > line and then re-build and re-run the test case. > > > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign > > that might give us useful info. > > > > Regards, > > Daniel > > > % LANG=C.UTF-8 tests/test-crypto-tlscredsx509 > # random seed: R02S9b95072a368ad370cdd4c780b8074596 > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > 2: signing structure using RSA-SHA256 > 3: ASSERT: common.c[_gnutls_x509_der_encode]:855 > 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174 > 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834 > 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152 > Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is > not valid. So it shows its failing inside a asn1_der_coding call, but I can't see why it would fail, especially if the same test suite passes fine on macOS x86_64 hosts. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 18:17 ` Daniel P. Berrangé @ 2021-01-27 18:56 ` Stefan Weil 2021-01-27 18:59 ` Daniel P. Berrangé 0 siblings, 1 reply; 27+ messages in thread From: Stefan Weil @ 2021-01-27 18:56 UTC (permalink / raw) To: Daniel P. Berrangé; +Cc: Peter Maydell, Alexander Graf, QEMU Developers Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé: > On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote: >> Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé: >> >>> In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS" >>> line and then re-build and re-run the test case. >>> >>> There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign >>> that might give us useful info. >>> >>> Regards, >>> Daniel >> >> % LANG=C.UTF-8 tests/test-crypto-tlscredsx509 >> # random seed: R02S9b95072a368ad370cdd4c780b8074596 >> 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 >> 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 >> 2: signing structure using RSA-SHA256 >> 3: ASSERT: common.c[_gnutls_x509_der_encode]:855 >> 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174 >> 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834 >> 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152 >> Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is >> not valid. > So it shows its failing inside a asn1_der_coding call, but I can't see > why it would fail, especially if the same test suite passes fine on > macOS x86_64 hosts. It returns ASN1_MEM_ERROR, so the input vector is too small. Stefan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 18:56 ` Stefan Weil @ 2021-01-27 18:59 ` Daniel P. Berrangé 2021-01-27 19:42 ` Stefan Weil 2021-01-29 8:43 ` Roman Bolshakov 0 siblings, 2 replies; 27+ messages in thread From: Daniel P. Berrangé @ 2021-01-27 18:59 UTC (permalink / raw) To: Stefan Weil; +Cc: Peter Maydell, Alexander Graf, QEMU Developers On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote: > Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé: > > > On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote: > > > Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé: > > > > > > > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS" > > > > line and then re-build and re-run the test case. > > > > > > > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign > > > > that might give us useful info. > > > > > > > > Regards, > > > > Daniel > > > > > > % LANG=C.UTF-8 tests/test-crypto-tlscredsx509 > > > # random seed: R02S9b95072a368ad370cdd4c780b8074596 > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > > > 2: signing structure using RSA-SHA256 > > > 3: ASSERT: common.c[_gnutls_x509_der_encode]:855 > > > 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174 > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834 > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152 > > > Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is > > > not valid. > > So it shows its failing inside a asn1_der_coding call, but I can't see > > why it would fail, especially if the same test suite passes fine on > > macOS x86_64 hosts. > > > It returns ASN1_MEM_ERROR, so the input vector is too small. Hmm, that's odd - "Value is not valid" corresponds to ASN1_VALUE_NOT_VALID error code. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 18:59 ` Daniel P. Berrangé @ 2021-01-27 19:42 ` Stefan Weil 2021-01-27 20:57 ` Stefan Weil 2021-01-29 8:43 ` Roman Bolshakov 1 sibling, 1 reply; 27+ messages in thread From: Stefan Weil @ 2021-01-27 19:42 UTC (permalink / raw) To: Daniel P. Berrangé; +Cc: Peter Maydell, Alexander Graf, QEMU Developers Am 27.01.21 um 19:59 schrieb Daniel P. Berrangé: > On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote: >> It returns ASN1_MEM_ERROR, so the input vector is too small. > Hmm, that's odd - "Value is not valid" corresponds to > ASN1_VALUE_NOT_VALID error code. I now have built libtasn1 with debug information and -O0 and can confirm that asn1_der_coding returns ASN1_MEM_ERROR. That's not surprising because it is called with *len == 0, while it requires at least 398. Stefan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 19:42 ` Stefan Weil @ 2021-01-27 20:57 ` Stefan Weil 0 siblings, 0 replies; 27+ messages in thread From: Stefan Weil @ 2021-01-27 20:57 UTC (permalink / raw) To: Daniel P. Berrangé; +Cc: Peter Maydell, Alexander Graf, QEMU Developers Am 27.01.21 um 20:42 schrieb Stefan Weil: > Am 27.01.21 um 19:59 schrieb Daniel P. Berrangé: > >> On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote: >>> It returns ASN1_MEM_ERROR, so the input vector is too small. >> Hmm, that's odd - "Value is not valid" corresponds to >> ASN1_VALUE_NOT_VALID error code. > > > I now have built libtasn1 with debug information and -O0 and can > confirm that asn1_der_coding returns ASN1_MEM_ERROR. > > That's not surprising because it is called with *len == 0, while it > requires at least 398. My previous report was incomplete. It's a normal pattern that asn1_der_coding is first called with vector length 0, then returns ASN1_MEM_ERROR and the required length which is used to allocate memory for the following call, so that was a false track. The debug libtasn1 gives a different output: % LANG=C tests/test-crypto-tlscredsx509 # random seed: R02S478dda7333f4b9f0f84d8d2a7da7eb08 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: Disabling X.509 extensions. 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 2: signing structure using RSA-SHA256 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_export]:2961 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_export]:2961 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_export]:2961 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_export]:2961 1..39 # Start of qcrypto tests # Start of tlscredsx509 tests 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 1 /qcrypto/tlscredsx509/perfectserver 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 2 /qcrypto/tlscredsx509/perfectclient 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 3 /qcrypto/tlscredsx509/goodca1 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 4 /qcrypto/tlscredsx509/goodca2 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 5 /qcrypto/tlscredsx509/goodca3 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: verify.c[verify_crt]:758 3: ASSERT: verify.c[verify_crt]:824 3: ASSERT: verify.c[verify_crt]:831 3: ASSERT: verify.c[_gnutls_verify_crt_status]:1023 ok 6 /qcrypto/tlscredsx509/badca1 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 ok 7 /qcrypto/tlscredsx509/badca2 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 ok 8 /qcrypto/tlscredsx509/badca3 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 9 /qcrypto/tlscredsx509/goodserver1 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 10 /qcrypto/tlscredsx509/goodserver2 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 11 /qcrypto/tlscredsx509/goodserver3 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 12 /qcrypto/tlscredsx509/goodserver4 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 13 /qcrypto/tlscredsx509/goodserver5 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 14 /qcrypto/tlscredsx509/goodserver6 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 15 /qcrypto/tlscredsx509/goodserver7 ok 16 /qcrypto/tlscredsx509/badserver1 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 ok 17 /qcrypto/tlscredsx509/badserver2 ok 18 /qcrypto/tlscredsx509/badserver3 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 19 /qcrypto/tlscredsx509/goodclient1 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 20 /qcrypto/tlscredsx509/goodclient2 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 21 /qcrypto/tlscredsx509/goodclient3 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 22 /qcrypto/tlscredsx509/goodclient4 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 23 /qcrypto/tlscredsx509/goodclient5 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 24 /qcrypto/tlscredsx509/goodclient6 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ok 25 /qcrypto/tlscredsx509/goodclient7 ok 26 /qcrypto/tlscredsx509/badclient1 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 ok 27 /qcrypto/tlscredsx509/badclient2 ok 28 /qcrypto/tlscredsx509/badclient3 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 ok 29 /qcrypto/tlscredsx509/expired1 ok 30 /qcrypto/tlscredsx509/expired2 ok 31 /qcrypto/tlscredsx509/expired3 3: ASSERT: common.c[_gnutls_copy_string]:1571 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3465 3: ASSERT: x509_ext.c[gnutls_x509_key_purpose_get]:3040 3: ASSERT: x509.c[gnutls_x509_crt_get_key_purpose_oid]:3459 3: ASSERT: x509.c[gnutls_x509_crt_get_authority_key_id]:1524 3: ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:469 3: ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:110 3: ASSERT: x509.c[get_alt_name]:1854 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 ** ERROR:../../../tests/test-crypto-tlscredsx509.c:119:test_tls_creds: assertion failed: (creds == NULL) Bail out! ERROR:../../../tests/test-crypto-tlscredsx509.c:119:test_tls_creds: assertion failed: (creds == NULL) zsh: abort LANG=C tests/test-crypto-tlscredsx509 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-27 18:59 ` Daniel P. Berrangé 2021-01-27 19:42 ` Stefan Weil @ 2021-01-29 8:43 ` Roman Bolshakov 2021-01-29 9:53 ` Daniel P. Berrangé 1 sibling, 1 reply; 27+ messages in thread From: Roman Bolshakov @ 2021-01-29 8:43 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Stefan Weil, Alexander Graf, QEMU Developers, Peter Maydell On Wed, Jan 27, 2021 at 06:59:17PM +0000, Daniel P. Berrangé wrote: > On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote: > > Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé: > > > > > On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote: > > > > Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé: > > > > > > > > > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS" > > > > > line and then re-build and re-run the test case. > > > > > > > > > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign > > > > > that might give us useful info. > > > > > > > > > > Regards, > > > > > Daniel > > > > > > > > % LANG=C.UTF-8 tests/test-crypto-tlscredsx509 > > > > # random seed: R02S9b95072a368ad370cdd4c780b8074596 > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > > > > 2: signing structure using RSA-SHA256 > > > > 3: ASSERT: common.c[_gnutls_x509_der_encode]:855 > > > > 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174 > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834 > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152 > > > > Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is > > > > not valid. > > > So it shows its failing inside a asn1_der_coding call, but I can't see > > > why it would fail, especially if the same test suite passes fine on > > > macOS x86_64 hosts. > > > > > > It returns ASN1_MEM_ERROR, so the input vector is too small. > > Hmm, that's odd - "Value is not valid" corresponds to > ASN1_VALUE_NOT_VALID error code. > Hi Daniel, Stefan, It's interesting that "make check" of libtasn1 fails with three tests and two of them produce VALUE_NOT_VALID error. The failing tests are: FAIL: Test_parser FAIL: Test_tree FAIL: copynode Full test log: =============================================== GNU Libtasn1 4.16.0: tests/test-suite.log =============================================== # TOTAL: 30 # PASS: 27 # SKIP: 0 # XFAIL: 0 # FAIL: 3 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: Test_parser ================= ERROR N. 1: Line 5 - TEST_PARSER2 { } DEFINITIONS IMPLICIT TAGS ::= BEGIN int1 ::= INTEGER END Error expected: SYNTAX_ERROR - Test_parser_ERROR.asn:6: Error: syntax error, unexpected IDENTIFIER, expecting $end near 'TEST_PARSER' Error detected: SYNTAX_ERROR - Test_parser_ERROR.asn:6: Error: syntax error, unexpected IDENTIFIER, expecting end of file near 'TEST_PARSER' FAIL Test_parser (exit status: 1) FAIL: Test_tree =============== ./Test_tree.asn:121: Warning: VisibleString is a built-in ASN.1 type. ./Test_tree.asn:123: Warning: NumericString is a built-in ASN.1 type. ./Test_tree.asn:125: Warning: IA5String is a built-in ASN.1 type. ./Test_tree.asn:127: Warning: TeletexString is a built-in ASN.1 type. ./Test_tree.asn:129: Warning: PrintableString is a built-in ASN.1 type. ./Test_tree.asn:131: Warning: UniversalString is a built-in ASN.1 type. ./Test_tree.asn:134: Warning: BMPString is a built-in ASN.1 type. ./Test_tree.asn:138: Warning: UTF8String is a built-in ASN.1 type. Error at line 707 ERROR in 254: Action 18 - Error expected: MEM_ERROR - 79 Error detected: VALUE_NOT_VALID - 0 FAIL Test_tree (exit status: 1) FAIL: copynode ============== ./pkix.asn:332: Warning: VisibleString is a built-in ASN.1 type. ./pkix.asn:334: Warning: NumericString is a built-in ASN.1 type. ./pkix.asn:336: Warning: IA5String is a built-in ASN.1 type. ./pkix.asn:338: Warning: TeletexString is a built-in ASN.1 type. ./pkix.asn:340: Warning: PrintableString is a built-in ASN.1 type. ./pkix.asn:342: Warning: UniversalString is a built-in ASN.1 type. ./pkix.asn:345: Warning: BMPString is a built-in ASN.1 type. ./pkix.asn:349: Warning: UTF8String is a built-in ASN.1 type. LIBTASN1 ERROR: VALUE_NOT_VALID Cannot copy node FAIL copynode (exit status: 1) Regards, Roman ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-29 8:43 ` Roman Bolshakov @ 2021-01-29 9:53 ` Daniel P. Berrangé 2021-02-02 5:19 ` Roman Bolshakov 0 siblings, 1 reply; 27+ messages in thread From: Daniel P. Berrangé @ 2021-01-29 9:53 UTC (permalink / raw) To: Roman Bolshakov Cc: Stefan Weil, Alexander Graf, QEMU Developers, Peter Maydell On Fri, Jan 29, 2021 at 11:43:32AM +0300, Roman Bolshakov wrote: > On Wed, Jan 27, 2021 at 06:59:17PM +0000, Daniel P. Berrangé wrote: > > On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote: > > > Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé: > > > > > > > On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote: > > > > > Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé: > > > > > > > > > > > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS" > > > > > > line and then re-build and re-run the test case. > > > > > > > > > > > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign > > > > > > that might give us useful info. > > > > > > > > > > > > Regards, > > > > > > Daniel > > > > > > > > > > % LANG=C.UTF-8 tests/test-crypto-tlscredsx509 > > > > > # random seed: R02S9b95072a368ad370cdd4c780b8074596 > > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > > > > > 2: signing structure using RSA-SHA256 > > > > > 3: ASSERT: common.c[_gnutls_x509_der_encode]:855 > > > > > 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174 > > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834 > > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152 > > > > > Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is > > > > > not valid. > > > > So it shows its failing inside a asn1_der_coding call, but I can't see > > > > why it would fail, especially if the same test suite passes fine on > > > > macOS x86_64 hosts. > > > > > > > > > It returns ASN1_MEM_ERROR, so the input vector is too small. > > > > Hmm, that's odd - "Value is not valid" corresponds to > > ASN1_VALUE_NOT_VALID error code. > > > > Hi Daniel, Stefan, > > It's interesting that "make check" of libtasn1 fails with three tests > and two of them produce VALUE_NOT_VALID error. > > The failing tests are: > FAIL: Test_parser > FAIL: Test_tree > FAIL: copynode That's interesting. Assuming 'make check' for libtasn1 succeeeds on x86_64 macOS, then I'm inclined to blame this whole problem on libtasn1 not QEMU. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-29 9:53 ` Daniel P. Berrangé @ 2021-02-02 5:19 ` Roman Bolshakov 2021-02-02 14:19 ` qemu_oss--- via 2021-02-02 14:50 ` Eric Blake 0 siblings, 2 replies; 27+ messages in thread From: Roman Bolshakov @ 2021-02-02 5:19 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Stefan Weil, Alexander Graf, QEMU Developers, Peter Maydell On Fri, Jan 29, 2021 at 09:53:27AM +0000, Daniel P. Berrangé wrote: > On Fri, Jan 29, 2021 at 11:43:32AM +0300, Roman Bolshakov wrote: > > On Wed, Jan 27, 2021 at 06:59:17PM +0000, Daniel P. Berrangé wrote: > > > On Wed, Jan 27, 2021 at 07:56:16PM +0100, Stefan Weil wrote: > > > > Am 27.01.21 um 19:17 schrieb Daniel P. Berrangé: > > > > > > > > > On Wed, Jan 27, 2021 at 06:05:08PM +0100, Stefan Weil wrote: > > > > > > Am 27.01.21 um 17:53 schrieb Daniel P. Berrangé: > > > > > > > > > > > > > In $QEMU.git/crypto/init.c can you uncomment the "#define DEBUG_GNUTLS" > > > > > > > line and then re-build and re-run the test case. > > > > > > > > > > > > > > There's a bunch of debug logs in code paths from gnutls_x509_crt_privkey_sign > > > > > > > that might give us useful info. > > > > > > > > > > > > > > Regards, > > > > > > > Daniel > > > > > > > > > > > > % LANG=C.UTF-8 tests/test-crypto-tlscredsx509 > > > > > > # random seed: R02S9b95072a368ad370cdd4c780b8074596 > > > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > > > > > > 3: ASSERT: mpi.c[wrap_nettle_mpi_print]:60 > > > > > > 2: signing structure using RSA-SHA256 > > > > > > 3: ASSERT: common.c[_gnutls_x509_der_encode]:855 > > > > > > 3: ASSERT: sign.c[_gnutls_x509_pkix_sign]:174 > > > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_privkey_sign]:1834 > > > > > > 3: ASSERT: x509_write.c[gnutls_x509_crt_sign2]:1152 > > > > > > Bail out! FATAL-CRITICAL: Failed to sign certificate ASN1 parser: Value is > > > > > > not valid. > > > > > So it shows its failing inside a asn1_der_coding call, but I can't see > > > > > why it would fail, especially if the same test suite passes fine on > > > > > macOS x86_64 hosts. > > > > > > > > > > > > It returns ASN1_MEM_ERROR, so the input vector is too small. > > > > > > Hmm, that's odd - "Value is not valid" corresponds to > > > ASN1_VALUE_NOT_VALID error code. > > > > > > > Hi Daniel, Stefan, > > > > It's interesting that "make check" of libtasn1 fails with three tests > > and two of them produce VALUE_NOT_VALID error. > > > > The failing tests are: > > FAIL: Test_parser > > FAIL: Test_tree > > FAIL: copynode > > That's interesting. Assuming 'make check' for libtasn1 succeeeds on > x86_64 macOS, then I'm inclined to blame this whole problem on > libtasn1 not QEMU. > 'make check' of libtasn1 doesn't succeed on x86_64 either. After a session of debugging I believe there's an issue with Clang 12. Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID from _asn1_time_der() in libtasn1): #include <stdio.h> static int func2(char *foo) { fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); if (foo == NULL) { fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); return 1; } return 0; } int func1(char *foo) { int counter = 0; if (fprintf(stderr, "IO\n") > 0) counter += 10; fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, counter); if(!func2(foo + counter)) { fprintf(stderr, "good\n"); return 0; } else { fprintf(stderr, "broken\n"); return 1; } } int main() { char *foo = NULL; return func1(foo); } What return value would you expect from the program? If the program is compiled with -O0/O1 it returns zero exit code. Here's the output: IO func1:16 foo: 0x0 counter 10 func2:4 foo: 0xa good If it is compiled with -O2 it returns 1: IO func1:16 foo: 0x0 counter 10 func2:4 foo: 0xa func2:6 foo: 0x0 broken That happens because clang uses register behind foo from func1 (it has zero pointer) inside inlined func2 (it should have non zero pointer). So, immediate workaround would be to downgrade optimization level of libtasn1 to -O1 in homebrew. I've submitted the issue to Apple bugtracker: FB8986815 Best regards, Roman ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-02-02 5:19 ` Roman Bolshakov @ 2021-02-02 14:19 ` qemu_oss--- via 2021-02-02 14:50 ` Eric Blake 1 sibling, 0 replies; 27+ messages in thread From: qemu_oss--- via @ 2021-02-02 14:19 UTC (permalink / raw) To: qemu-devel Cc: Stefan Weil, Roman Bolshakov, Alexander Graf, Daniel P. Berrangé, Peter Maydell On Dienstag, 2. Februar 2021 06:19:42 CET Roman Bolshakov wrote: > 'make check' of libtasn1 doesn't succeed on x86_64 either. > > After a session of debugging I believe there's an issue with Clang 12. > Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID > from _asn1_time_der() in libtasn1): > > #include <stdio.h> > > static int func2(char *foo) { > fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); > if (foo == NULL) { > fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); > return 1; > } > return 0; > } > > int func1(char *foo) { > int counter = 0; > if (fprintf(stderr, "IO\n") > 0) > counter += 10; > fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, > foo, counter); if(!func2(foo + counter)) { > fprintf(stderr, "good\n"); > return 0; > } else { > fprintf(stderr, "broken\n"); > return 1; > } > } > > int main() { > char *foo = NULL; > return func1(foo); > } > > > What return value would you expect from the program? > > If the program is compiled with -O0/O1 it returns zero exit code. > Here's the output: > IO > func1:16 foo: 0x0 counter 10 > func2:4 foo: 0xa > good > > If it is compiled with -O2 it returns 1: > IO > func1:16 foo: 0x0 counter 10 > func2:4 foo: 0xa > func2:6 foo: 0x0 > broken > > That happens because clang uses register behind foo from func1 (it has zero > pointer) inside inlined func2 (it should have non zero pointer). > > So, immediate workaround would be to downgrade optimization level of > libtasn1 to -O1 in homebrew. Hu, confirmed. clang 12.0.0 on x86_64 Mac fails on that demo with -O2,-O3,-Os, but works with -O0,-O1. clang 11.0.3 in contrast works with any optimization level. It only fails BTW if that test uses exactly a NULL pointer, any other memory address (e.g. just (void*)1) works: #include <stdio.h> #define FLOOR_VALUE ((void*)1) static int func2(char *foo) { fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); if (foo == FLOOR_VALUE) { fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); return 1; } return 0; } int func1(char *foo) { int counter = 0; if (fprintf(stderr, "IO\n") > 0) counter += 1; fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, counter); if(!func2(foo + counter)) { fprintf(stderr, "good\n"); return 0; } else { fprintf(stderr, "broken\n"); return 1; } } int main() { char *foo = FLOOR_VALUE; return func1(foo); } Maybe that's some sort of new security feature in clang 12, in the sense of something like this: VeryLargeStruct *p = NULL; p->farMember = value; to segfault always reliably and exactly with address zero, instead of pure luck as of NULL + veryLargeSize. > I've submitted the issue to Apple bugtracker: > FB8986815 > > Best regards, > Roman They could argue that operating on a NULL pointer is undefined behaviour. Best regards, Christian Schoenebeck ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-02-02 5:19 ` Roman Bolshakov 2021-02-02 14:19 ` qemu_oss--- via @ 2021-02-02 14:50 ` Eric Blake 2021-02-02 16:35 ` qemu_oss--- via ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: Eric Blake @ 2021-02-02 14:50 UTC (permalink / raw) To: Roman Bolshakov, Daniel P. Berrangé Cc: Stefan Weil, Alexander Graf, QEMU Developers, Peter Maydell On 2/1/21 11:19 PM, Roman Bolshakov wrote: > After a session of debugging I believe there's an issue with Clang 12. > Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID > from _asn1_time_der() in libtasn1): > > #include <stdio.h> > > static int func2(char *foo) { > fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); > if (foo == NULL) { > fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); > return 1; > } > return 0; > } > > int func1(char *foo) { > int counter = 0; > if (fprintf(stderr, "IO\n") > 0) > counter += 10; > fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, counter); > if(!func2(foo + counter)) { This line has unspecified behavior in the C standard. Adding an integer to a pointer is only well-specified if the pointer is to an array and the integer is within the bounds or the slot just past the array. But since you called func1(NULL), foo is NOT pointing to an array, and therefore foo+counter points to garbage, and the compiler is free to optimize it at will. > fprintf(stderr, "good\n"); > return 0; > } else { > fprintf(stderr, "broken\n"); > return 1; > } > } > > int main() { > char *foo = NULL; > return func1(foo); > } > > > What return value would you expect from the program? Because the code is not strictly compliant to the C standard, I'm not sure what to expect. > > If the program is compiled with -O0/O1 it returns zero exit code. > Here's the output: > IO > func1:16 foo: 0x0 counter 10 > func2:4 foo: 0xa > good > > If it is compiled with -O2 it returns 1: > IO > func1:16 foo: 0x0 counter 10 > func2:4 foo: 0xa > func2:6 foo: 0x0 And this proves the point that the compiler was able to exploit the undefined behavior in your program. > broken > > That happens because clang uses register behind foo from func1 (it has zero > pointer) inside inlined func2 (it should have non zero pointer). > > So, immediate workaround would be to downgrade optimization level of libtasn1 > to -O1 in homebrew. > > I've submitted the issue to Apple bugtracker: > FB8986815 Yes, it's annoying that as compilers get smarter, it exposes the presence of unspecified code in weird ways. But I don't see this as a bug in clang, but as a bug in libtasn1 for assuming undefined behavior produces a sane result. > > Best regards, > Roman > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-02-02 14:50 ` Eric Blake @ 2021-02-02 16:35 ` qemu_oss--- via 2021-02-02 17:14 ` Eric Blake 2021-02-02 16:50 ` Daniel P. Berrangé 2021-02-03 14:28 ` Roman Bolshakov 2 siblings, 1 reply; 27+ messages in thread From: qemu_oss--- via @ 2021-02-02 16:35 UTC (permalink / raw) To: qemu-devel Cc: Peter Maydell, Daniel P. Berrangé, Stefan Weil, Roman Bolshakov, Alexander Graf On Dienstag, 2. Februar 2021 15:50:24 CET Eric Blake wrote: > > If the program is compiled with -O0/O1 it returns zero exit code. > > Here's the output: > > IO > > func1:16 foo: 0x0 counter 10 > > func2:4 foo: 0xa > > good > > > > If it is compiled with -O2 it returns 1: > > IO > > func1:16 foo: 0x0 counter 10 > > func2:4 foo: 0xa > > func2:6 foo: 0x0 > > And this proves the point that the compiler was able to exploit the > undefined behavior in your program. > > > broken > > > > That happens because clang uses register behind foo from func1 (it has > > zero > > pointer) inside inlined func2 (it should have non zero pointer). > > > > So, immediate workaround would be to downgrade optimization level of > > libtasn1 to -O1 in homebrew. > > > > I've submitted the issue to Apple bugtracker: > > FB8986815 > > Yes, it's annoying that as compilers get smarter, it exposes the > presence of unspecified code in weird ways. But I don't see this as a > bug in clang, but as a bug in libtasn1 for assuming undefined behavior > produces a sane result. You are right Eric, but nevertheless it's a very aggressive behaviour change being introduced way too silent, especially regarding backward compatibility like this case proofs. Personally I find the new semantic NULL + n == NULL makes sense, as it adds safety, but I do consider it a bug that clang did not even throw a warning. Even when I add -Wnull-pointer-arithmetic it does not complain to me at all. Best regards, Christian Schoenebeck ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-02-02 16:35 ` qemu_oss--- via @ 2021-02-02 17:14 ` Eric Blake 2021-02-02 20:31 ` Stefan Weil 0 siblings, 1 reply; 27+ messages in thread From: Eric Blake @ 2021-02-02 17:14 UTC (permalink / raw) To: Christian Schoenebeck, qemu-devel Cc: Stefan Weil, Roman Bolshakov, Alexander Graf, Daniel P. Berrangé, Peter Maydell On 2/2/21 10:35 AM, Christian Schoenebeck wrote: >>> I've submitted the issue to Apple bugtracker: >>> FB8986815 >> >> Yes, it's annoying that as compilers get smarter, it exposes the >> presence of unspecified code in weird ways. But I don't see this as a >> bug in clang, but as a bug in libtasn1 for assuming undefined behavior >> produces a sane result. > > You are right Eric, but nevertheless it's a very aggressive behaviour change > being introduced way too silent, especially regarding backward compatibility > like this case proofs. > > Personally I find the new semantic NULL + n == NULL makes sense, as it adds > safety, but I do consider it a bug that clang did not even throw a warning. > Even when I add -Wnull-pointer-arithmetic it does not complain to me at all. Yes, you do have a valid argument: any compiler that is going to optimize on our undefined behavior, but fails to give us a -Wxyz option to ferret out those spots in our code in order to avoid them in the first place, has a poor QoI, and it is worth filing a bug against that compiler to have it not be so silent. Or put another way, there is a subtle difference between arguing that "the compiler is miscompiling my program" (which is demonstrably false per the standard's permission for the compiler to do whatever it wants on undefined code, but if true would represent a regression) and "the compiler is not helping me eradicate undefined behavior from my dusty-deck code" (which is demonstrably true), and the latter is definitely worthy of being designated a clang bug (but not regression, rather, you just got lucky that your code previously did what you wanted in spite of its undefinedness). And that applies whether or not we also pursue the parallel course of action of fixing the actual undefined-code bug in libtasn1 that triggered this discussion. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-02-02 17:14 ` Eric Blake @ 2021-02-02 20:31 ` Stefan Weil 2021-02-02 20:50 ` Stefan Weil 0 siblings, 1 reply; 27+ messages in thread From: Stefan Weil @ 2021-02-02 20:31 UTC (permalink / raw) To: Eric Blake, Christian Schoenebeck, qemu-devel Cc: Peter Maydell, Roman Bolshakov, Alexander Graf, Daniel P. Berrangé Am 02.02.21 um 18:14 schrieb Eric Blake: > Yes, you do have a valid argument: any compiler that is going to > optimize on our undefined behavior, but fails to give us a -Wxyz option > to ferret out those spots in our code in order to avoid them in the > first place, has a poor QoI, and it is worth filing a bug against that > compiler to have it not be so silent. Or put another way, there is a > subtle difference between arguing that "the compiler is miscompiling my > program" (which is demonstrably false per the standard's permission for > the compiler to do whatever it wants on undefined code, but if true > would represent a regression) and "the compiler is not helping me > eradicate undefined behavior from my dusty-deck code" (which is > demonstrably true), and the latter is definitely worthy of being > designated a clang bug (but not regression, rather, you just got lucky > that your code previously did what you wanted in spite of its > undefinedness). And that applies whether or not we also pursue the > parallel course of action of fixing the actual undefined-code bug in > libtasn1 that triggered this discussion. I agree that the compiler should have given a warning. It did not even with -Weverything. The code uses NULL + offset constructs, so requires a fix. https://gitlab.com/gnutls/libtasn1/-/merge_requests/71 fixes the unit tests of libtasn1 for me, maybe also the test for QEMU which I still have to check. Regards, Stefan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-02-02 20:31 ` Stefan Weil @ 2021-02-02 20:50 ` Stefan Weil 2021-02-03 10:00 ` Daniel P. Berrangé 0 siblings, 1 reply; 27+ messages in thread From: Stefan Weil @ 2021-02-02 20:50 UTC (permalink / raw) To: Eric Blake, Christian Schoenebeck, qemu-devel Cc: Peter Maydell, Roman Bolshakov, Alexander Graf, Daniel P. Berrangé Am 02.02.21 um 21:31 schrieb Stefan Weil: > The code uses NULL + offset constructs, so requires a fix. > > https://gitlab.com/gnutls/libtasn1/-/merge_requests/71 fixes the unit > tests of libtasn1 for me, maybe also the test for QEMU which I still > have to check. > The QEMU test passes with the patch for libtasn1: stefan@mini clang % tests/test-crypto-tlscredsx509 # random seed: R02S0b9c3f2459ee914a95bb1f9e28441dd9 1..39 # Start of qcrypto tests # Start of tlscredsx509 tests ok 1 /qcrypto/tlscredsx509/perfectserver ok 2 /qcrypto/tlscredsx509/perfectclient ok 3 /qcrypto/tlscredsx509/goodca1 ok 4 /qcrypto/tlscredsx509/goodca2 ok 5 /qcrypto/tlscredsx509/goodca3 ok 6 /qcrypto/tlscredsx509/badca1 ok 7 /qcrypto/tlscredsx509/badca2 ok 8 /qcrypto/tlscredsx509/badca3 ok 9 /qcrypto/tlscredsx509/goodserver1 ok 10 /qcrypto/tlscredsx509/goodserver2 ok 11 /qcrypto/tlscredsx509/goodserver3 ok 12 /qcrypto/tlscredsx509/goodserver4 ok 13 /qcrypto/tlscredsx509/goodserver5 ok 14 /qcrypto/tlscredsx509/goodserver6 ok 15 /qcrypto/tlscredsx509/goodserver7 ok 16 /qcrypto/tlscredsx509/badserver1 ok 17 /qcrypto/tlscredsx509/badserver2 ok 18 /qcrypto/tlscredsx509/badserver3 ok 19 /qcrypto/tlscredsx509/goodclient1 ok 20 /qcrypto/tlscredsx509/goodclient2 ok 21 /qcrypto/tlscredsx509/goodclient3 ok 22 /qcrypto/tlscredsx509/goodclient4 ok 23 /qcrypto/tlscredsx509/goodclient5 ok 24 /qcrypto/tlscredsx509/goodclient6 ok 25 /qcrypto/tlscredsx509/goodclient7 ok 26 /qcrypto/tlscredsx509/badclient1 ok 27 /qcrypto/tlscredsx509/badclient2 ok 28 /qcrypto/tlscredsx509/badclient3 ok 29 /qcrypto/tlscredsx509/expired1 ok 30 /qcrypto/tlscredsx509/expired2 ok 31 /qcrypto/tlscredsx509/expired3 ok 32 /qcrypto/tlscredsx509/inactive1 ok 33 /qcrypto/tlscredsx509/inactive2 ok 34 /qcrypto/tlscredsx509/inactive3 ok 35 /qcrypto/tlscredsx509/chain1 ok 36 /qcrypto/tlscredsx509/chain2 ok 37 /qcrypto/tlscredsx509/missingca ok 38 /qcrypto/tlscredsx509/missingserver ok 39 /qcrypto/tlscredsx509/missingclient # End of tlscredsx509 tests # End of qcrypto tests ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-02-02 20:50 ` Stefan Weil @ 2021-02-03 10:00 ` Daniel P. Berrangé 0 siblings, 0 replies; 27+ messages in thread From: Daniel P. Berrangé @ 2021-02-03 10:00 UTC (permalink / raw) To: Stefan Weil Cc: Peter Maydell, Christian Schoenebeck, qemu-devel, Roman Bolshakov, Alexander Graf On Tue, Feb 02, 2021 at 09:50:39PM +0100, Stefan Weil wrote: > Am 02.02.21 um 21:31 schrieb Stefan Weil: > > > The code uses NULL + offset constructs, so requires a fix. > > > > https://gitlab.com/gnutls/libtasn1/-/merge_requests/71 fixes the unit > > tests of libtasn1 for me, maybe also the test for QEMU which I still > > have to check. > > > > The QEMU test passes with the patch for libtasn1: That's great, thanks for chasing this problem. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-02-02 14:50 ` Eric Blake 2021-02-02 16:35 ` qemu_oss--- via @ 2021-02-02 16:50 ` Daniel P. Berrangé 2021-02-03 14:28 ` Roman Bolshakov 2 siblings, 0 replies; 27+ messages in thread From: Daniel P. Berrangé @ 2021-02-02 16:50 UTC (permalink / raw) To: Eric Blake Cc: Stefan Weil, Roman Bolshakov, Alexander Graf, QEMU Developers, Peter Maydell On Tue, Feb 02, 2021 at 08:50:24AM -0600, Eric Blake wrote: > On 2/1/21 11:19 PM, Roman Bolshakov wrote: > > > After a session of debugging I believe there's an issue with Clang 12. > > Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID > > from _asn1_time_der() in libtasn1): > > > > #include <stdio.h> > > > > static int func2(char *foo) { > > fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); > > if (foo == NULL) { > > fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); > > return 1; > > } > > return 0; > > } > > > > int func1(char *foo) { > > int counter = 0; > > if (fprintf(stderr, "IO\n") > 0) > > counter += 10; > > fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, counter); > > if(!func2(foo + counter)) { > > This line has unspecified behavior in the C standard. Adding an integer > to a pointer is only well-specified if the pointer is to an array and > the integer is within the bounds or the slot just past the array. But > since you called func1(NULL), foo is NOT pointing to an array, and > therefore foo+counter points to garbage, and the compiler is free to > optimize it at will. > > > fprintf(stderr, "good\n"); > > return 0; > > } else { > > fprintf(stderr, "broken\n"); > > return 1; > > } > > } > > > > int main() { > > char *foo = NULL; > > return func1(foo); > > } > > > > > > What return value would you expect from the program? > > Because the code is not strictly compliant to the C standard, I'm not > sure what to expect. Roman invented this example to illustrate the problem with libtasn1, so I wonder if this suggests that libtasn1 is relying on undefined C behaviour too. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-02-02 14:50 ` Eric Blake 2021-02-02 16:35 ` qemu_oss--- via 2021-02-02 16:50 ` Daniel P. Berrangé @ 2021-02-03 14:28 ` Roman Bolshakov 2 siblings, 0 replies; 27+ messages in thread From: Roman Bolshakov @ 2021-02-03 14:28 UTC (permalink / raw) To: Eric Blake Cc: Stefan Weil, Alexander Graf, Daniel P. Berrangé, QEMU Developers, Peter Maydell On Tue, Feb 02, 2021 at 08:50:24AM -0600, Eric Blake wrote: > On 2/1/21 11:19 PM, Roman Bolshakov wrote: > > > After a session of debugging I believe there's an issue with Clang 12. > > Here's a test program (it reproduces unexpected ASN1_VALUE_NOT_VALID > > from _asn1_time_der() in libtasn1): > > > > #include <stdio.h> > > > > static int func2(char *foo) { > > fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); > > if (foo == NULL) { > > fprintf(stderr, "%s:%d foo: %p\n", __func__, __LINE__, foo); > > return 1; > > } > > return 0; > > } > > > > int func1(char *foo) { > > int counter = 0; > > if (fprintf(stderr, "IO\n") > 0) > > counter += 10; > > fprintf(stderr, "%s:%d foo: %p counter %d\n", __func__, __LINE__, foo, counter); > > if(!func2(foo + counter)) { > > This line has unspecified behavior in the C standard. Adding an integer > to a pointer is only well-specified if the pointer is to an array and > the integer is within the bounds or the slot just past the array. But > since you called func1(NULL), foo is NOT pointing to an array, and > therefore foo+counter points to garbage, and the compiler is free to > optimize it at will. Hi Eric, Thanks a lot for pointing out this. It was surprising to me but interesting: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2012.htm#clarifying-the-c-memory-object-model-out-of-bounds-pointer-arithmetic http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2222.htm#pointer-arithmetic As far as I understand wording in the standard, null pointer doesn't point to an object (6.3.2.3p3). Therefore pointer arithmetic exception for non-array objects (6.5.6p7) doesn't apply to null pointers but it does apply to valid object pointers: "For the purposes of these operators, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type." So I was curious how clang would behave if we pass NULL conditionally. We could do that by changing main() in the example above to: int main(int argc, char *argv[]) { int ret; char *foo; if (argc > 1) foo = malloc(90 * sizeof(char)); else foo = NULL; ret = func1(foo); if (argc > 1) free(foo); return ret; } And it returns "good" for specified behaviour (if foo points to malloc'd memory): $ ./a.out f IO func1:17 foo: 0x14be06790 counter 10 func2:5 foo: 0x14be0679a good The behaviour is different if foo is initialized to NULL. $ ./a.out IO func1:17 foo: 0x0 counter 10 func2:5 foo: 0xa func2:7 foo: 0x0 broken > > > > So, immediate workaround would be to downgrade optimization level of libtasn1 > > to -O1 in homebrew. > > > > I've submitted the issue to Apple bugtracker: > > FB8986815 > > Yes, it's annoying that as compilers get smarter, it exposes the > presence of unspecified code in weird ways. But I don't see this as a > bug in clang, but as a bug in libtasn1 for assuming undefined behavior > produces a sane result. > Yes, strictly speaking the compiler is compliant. Given the example libtasn1 should likely introduce a second variable for an integer offset instead of relying on null pointer arithmetic. It'd also be good if clang would print an error or a warning for null pointer arithmetic. Thanks, Roman ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 2021-01-26 16:32 macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 Peter Maydell 2021-01-26 16:36 ` Daniel P. Berrangé @ 2021-02-02 5:46 ` 罗勇刚(Yonggang Luo) 1 sibling, 0 replies; 27+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2021-02-02 5:46 UTC (permalink / raw) To: Peter Maydell; +Cc: Alexander Graf, Daniel P. Berrange, QEMU Developers [-- Attachment #1: Type: text/plain, Size: 1548 bytes --] SHA-1: 94c13c1048378cbffe552b6fe5c960dc04eaefb2 * gcrypt: test_tls_psk_init should write binary file instead text file. On windows, if open file with "w", it's will automatically convert "\n" to "\r\n" when writing to file. Signed-off-by: Yonggang Luo <luoyonggang@gmail.com> Is this related? On Wed, Jan 27, 2021 at 12:37 AM Peter Maydell <peter.maydell@linaro.org> wrote: > My Big Sur/Apple Silicon system fails "make check" in > test-crypto-tlscredsx509: > > MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} > G_TEST_SRCDIR=/Users/pm215/qemu/tests > G_TEST_BUILDDIR=/Users/pm215/qemu/build/all/tests > tests/test-crypto-tlscredsx509 --tap -k > > ** (tests/test-crypto-tlscredsx509:35180): CRITICAL **: 16:23:34.590: > Failed to sign certificate ASN1 parser: Value is not valid. > ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to > sign certificate ASN1 parser: Value is not valid. > make: *** [run-test-70] Error 1 > > > Does this failure ring any bells for anybody? > > Here's the crypto part of the meson-log: > > Crypto > TLS priority: "NORMAL" > GNUTLS support: YES > libgcrypt: NO > nettle: YES > XTS: YES > crypto afalg: NO > rng-none: NO > Linux keyring: NO > > > thanks > -- PMM > > -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo [-- Attachment #2: Type: text/html, Size: 2225 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2021-02-03 14:37 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-26 16:32 macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509 Peter Maydell 2021-01-26 16:36 ` Daniel P. Berrangé 2021-01-26 16:41 ` Peter Maydell 2021-01-27 12:17 ` Daniel P. Berrangé 2021-01-27 12:35 ` Christian Schoenebeck 2021-01-27 12:38 ` Daniel P. Berrangé 2021-01-27 16:44 ` Stefan Weil 2021-01-27 16:53 ` Daniel P. Berrangé 2021-01-27 17:05 ` Stefan Weil 2021-01-27 18:17 ` Daniel P. Berrangé 2021-01-27 18:56 ` Stefan Weil 2021-01-27 18:59 ` Daniel P. Berrangé 2021-01-27 19:42 ` Stefan Weil 2021-01-27 20:57 ` Stefan Weil 2021-01-29 8:43 ` Roman Bolshakov 2021-01-29 9:53 ` Daniel P. Berrangé 2021-02-02 5:19 ` Roman Bolshakov 2021-02-02 14:19 ` qemu_oss--- via 2021-02-02 14:50 ` Eric Blake 2021-02-02 16:35 ` qemu_oss--- via 2021-02-02 17:14 ` Eric Blake 2021-02-02 20:31 ` Stefan Weil 2021-02-02 20:50 ` Stefan Weil 2021-02-03 10:00 ` Daniel P. Berrangé 2021-02-02 16:50 ` Daniel P. Berrangé 2021-02-03 14:28 ` Roman Bolshakov 2021-02-02 5:46 ` 罗勇刚(Yonggang Luo)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).