From owner-freebsd-current@freebsd.org Wed Jun 10 20:16:42 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2CE1E33EC03 for ; Wed, 10 Jun 2020 20:16:42 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49hytx5Ntwz4WyH; Wed, 10 Jun 2020 20:16:41 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2a02:8109:1140:c3d:7000:7152:c399:835] (unknown [IPv6:2a02:8109:1140:c3d:7000:7152:c399:835]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id D41577220B802; Wed, 10 Jun 2020 22:16:37 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: gcc versus clang issue for 32-bit binaries From: Michael Tuexen In-Reply-To: Date: Wed, 10 Jun 2020 22:16:35 +0200 Cc: Mark Johnston , "freebsd-current@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <55C26C30-15C3-46E2-A449-6A0416D86798@freebsd.org> References: <128AB51F-0950-448F-8463-12C573C1AA38@freebsd.org> <20200610165908.GA81346@raichu> <0281EB7A-B5DE-4D52-96DF-C7A2D6DC805C@freebsd.org> To: Damjan Jovanovic X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 49hytx5Ntwz4WyH X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; TAGGED_RCPT(0.00)[]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 20:16:42 -0000 > On 10. Jun 2020, at 20:30, Damjan Jovanovic = wrote: >=20 > MAP_FIXED is generally bad news, as it overwrites any prior mappings = within the range of addresses being mapped to. >=20 > They should use MAP_FIXED | MAP_EXCL instead, which will fail if any = mappings already exist in the range, and then maybe retry with another = range if it fails. Linux and NetBSD have MAP_TRYFIXED instead, which = does the retrying internally. Or at the very least, run mincore() on = every page in the range to verify that nothing is mapped before using = mmap() with MAP_FIXED. It is used in syzkaller. Some go code generates C include files... So = right now I might want to stick with a value. >=20 > If there is no other way but to use a single hardcoded value, check = /proc//map for a number of different processes, 32 and 64 bit, and = find an address range that isn't used often. Thanks for the hint. I tried to find one. Let's see how good this guess = is. Best regards Michael >=20 > Damjan >=20 >=20 > On Wed, Jun 10, 2020 at 7:40 PM Michael Tuexen = wrote: > > On 10. Jun 2020, at 18:59, Mark Johnston wrote: > >=20 > > On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote: > >> Dear all, > >>=20 > >> consider the following program test.c: > >>=20 > >> #include > >> #include > >>=20 > >> int=20 > >> main(void) > >> { > >> void *p; > >> =20 > >> p =3D mmap((void *)0x20000000, 0x1000000, PROT_READ | = PROT_WRITE | PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0); > >> printf("p=3D %p\n", p); > >> return (0); > >> } > >>=20 > >> On i386 the following happens: > >> * when compiling it with cc and running it, it crashes. > >> * when compiling it with gcc it runs fine. > >>=20 > >> On amd64 the following happens: > >> * when compiling it with cc -m64 it runs fine. > >> * when compiling it with cc -m32 is crashes. > >> * when compiling it with gcc -m64 it runs fine. > >> * when compiling it with gcc -m32 it runs fine. > >>=20 > >> So why does the above program crash when compiled for 32-bit when = using clang, but runs fine when compiled with gcc. > >=20 > > The difference is between ld.bfd and ld.lld, which emit executables = with > > different entry point addresses. cc -m32 -fuse-ld=3Dbfd gives an > > executable that does not crash. > >=20 > > When linked with lld, libc and ld-elf get mapped into the region > > [0x20000000,0x21000000], so the program crashes when the libc.so = mapping > > is overwritten with that created by the mmap() call and the program > > calls printf(). > >=20 > >> I'm testing this on 32-bit and 64-bit head systems. gcc is from = ports. > >>=20 > >> The reason I'm looking into it is that I want to get syzkaller = working on 32-bit with clang. > >=20 > > Do you know why SYZ_DATA_OFFSET is hard-coded the way it is? It = looks > > like it works more or less by accident, but at a glance I don't see = why > > it has to be a fixed mapping. > I don't know, it comes from: > = https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L45= 0 >=20 > Do you have a value which can be used on FreeBSD? Then we can just = change it... >=20 > Best regards > Michael >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"