From owner-freebsd-arch@FreeBSD.ORG Thu Jul 24 00:46:01 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 00878C69 for ; Thu, 24 Jul 2014 00:46:00 +0000 (UTC) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C140D2D8A for ; Thu, 24 Jul 2014 00:46:00 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id bj1so2727403pad.25 for ; Wed, 23 Jul 2014 17:45:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cKMJ3dIowaAUo5lF9A2yKKo+4d5kpTn6KqSBsCHXy2E=; b=hl2o8f6ZmpjPrb9WpjyUBGc9xzg370IiLT5DNOVWE9RqvvALlEDerkeRekCkTVScit uRNhCrYQX87DvAV4AU0M2t/T7jZZSAwZODXbw5WN5z9rvpYCkJGbV/UluEPf4HIzORF5 K0P3okKqgKY6YrnKklqjsQbAvpKESb0MKQooz2UIzMIJor6aPUMttM/X+4IKWq+bzJxb cDLNpiR5Q8z2FuLxsfnKOd9gcB8LEpAxl10oJnDZ4WKyaDTxG5VMGbQFbYJc+WP7pec7 fThANXIR8pHav0dzwMP8Hu44Ssj/SFTDWapvpvXj9B1egmswpHw7lMBdIJYdc9TPrgEA PGjQ== X-Gm-Message-State: ALoCoQlLAl2/J/aSK3w5v/1h3SirRFRd21Zw4++hGYJpmaaCKSYS4zGEfG0Pz3oA5jOzmQcMMHql X-Received: by 10.66.236.35 with SMTP id ur3mr6252957pac.35.1406162753554; Wed, 23 Jul 2014 17:45:53 -0700 (PDT) Received: from [192.168.1.103] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id vu7sm14208334pab.34.2014.07.23.17.45.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 17:45:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch From: Tim Kientzle In-Reply-To: Date: Wed, 23 Jul 2014 17:45:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <796EDB88-3768-48AA-B909-8A7FFBED0C1E@kientzle.com> References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <20140723004543.GH29618@pwnie.vrt.sourcefire.com> To: Pedro Giffuni X-Mailer: Apple Mail (2.1878.6) Cc: Shawn Webb , Oliver Pinter , Robert Watson , freebsd-arch@freebsd.org, PaX Team , Bryan Drewery 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 00:46:01 -0000 On Jul 23, 2014, at 4:37 PM, Pedro Giffuni wrote: > Hi; >=20 > Il giorno 22/lug/2014, alle ore 19:45, Shawn Webb = ha scritto: >=20 >>>> ... >>>=20 >>> Hi Shawn: >>>=20 >>> Great news that this work is coming to fruition -- ASLR is long = overdue. >>>=20 >>> Are you having any luck with performance measurements? Unixbench = seems 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 = affected as a=20 >>> result of changes in kernel VM data-structure use, or greater = fragmentation of=20 >>> 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 tend 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 >=20 > Somewhat related to ElectricFence=85 will ASLR have an adverse effect = on debuggers? >=20 > I googled around and got to this: >=20 > http://www.outflux.net/blog/archives/2010/07/03/gdb-turns-off-aslr/ >=20 > So I guess we may have to patch gdb (and lldb)? I suspect the issue here is that debugging often requires multiple runs of a program with repeatable behavior between runs. Consider: * I run the program under GDB, it crashes at a certain PC address * I restart the program, set a breakpoint at that PC address I want to be confident that the PC address where I=92m setting the breakpoint will have the same meaning between runs. Tim