From owner-freebsd-arch@FreeBSD.ORG Thu Jul 24 07:51:53 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F395B63; Thu, 24 Jul 2014 07:51:53 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF412069; Thu, 24 Jul 2014 07:51:53 +0000 (UTC) Received: from [10.218.87.102] (unknown [85.255.233.71]) by cyrus.watson.org (Postfix) with ESMTPSA id 6A4FD46B38; Thu, 24 Jul 2014 03:51:51 -0400 (EDT) References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <20140723004543.GH29618@pwnie.vrt.sourcefire.com> <20140723234455.GP29618@pwnie.vrt.sourcefire.com> Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <860889F3-EA75-4C08-A1A4-904CE7A94899@FreeBSD.org> X-Mailer: iPad Mail (11D257) From: "Robert N. M. Watson" Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch Date: Thu, 24 Jul 2014 08:51:47 +0100 To: Pedro Giffuni Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: PaX Team , "freebsd-arch@freebsd.org" , Oliver Pinter , Bryan Drewery , Shawn Webb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 07:51:53 -0000 >>>>> Great news that this work is coming to fruition -- ASLR is long overdu= e. >>>>>=20 >>>>> Are you having any luck with performance measurements? Unixbench seem= s like a=20 >>>>> good starting point, but I wonder if it would be useful to look, in=20= >>>>> particular, at memory-mapping intensive workloads that might be affect= ed as a=20 >>>>> result of changes in kernel VM data-structure use, or greater fragment= ation of >>>>> the address space. I'm not sure I have a specific application here in= mind --=20 >>>>> in the past I might have pointed out tools such as ElectricFence that t= end to=20 >>>>> increase fragmentation themselves. >>>>=20 >>>> The unixbench tests on that laptop have finished. However, I've been >>>> fighting a pesky migraine these last couple days, so I haven't had the >>>> opportunity to aggregate the results into a nice little spreadsheet. I'= m >>>> hoping to finish it up by the end of the week. >>>>=20 >>>> I'll take a look at ElectricFence this weekend. Additionally, I have a >>>> netbook somewhere. Once I find it and its power cord, I'll install >>>> FreeBSD/x86 and re-run the same tests on that. >>>=20 >>> Somewhat related to ElectricFence? will ASLR have an adverse effect on d= ebuggers? >>>=20 >>> I googled around and got to this: >>>=20 >>> http://www.outflux.net/blog/archives/2010/07/03/gdb-turns-off-aslr/ >>=20 >> I've been doing all my ClamAV development on my FreeBSD box with ASLR >> enabled. Development tools like gdb and valgrind work great, even with >> corefiles. I have not, however, tried lldb. >=20 > OK, but it=E2=80=99s worth to take a look if we need to support something t= o turn it off. > Apparently gdb disables ASLR on MacOSX too: >=20 > http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/ >=20 > Pedro. >=20