From: qemu_oss--- via <qemu-devel@nongnu.org>
To: qemu-devel@nongnu.org
Cc: "Stefan Weil" <sw@weilnetz.de>,
"Roman Bolshakov" <r.bolshakov@yadro.com>,
"Alexander Graf" <agraf@csgraf.de>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>
Subject: Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509
Date: Tue, 02 Feb 2021 15:19:07 +0100 [thread overview]
Message-ID: <4977531.9KTcbTlzxt@silver> (raw)
In-Reply-To: <YBjg7ubtbw3OeQCd@SPB-NB-133.local>
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
next prev parent reply other threads:[~2021-02-02 14:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4977531.9KTcbTlzxt@silver \
--to=qemu-devel@nongnu.org \
--cc=agraf@csgraf.de \
--cc=berrange@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu_oss@crudebyte.com \
--cc=r.bolshakov@yadro.com \
--cc=sw@weilnetz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.