From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 23:28:31 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C244F00; Tue, 22 Jul 2014 23:28:31 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id D722723CA; Tue, 22 Jul 2014 23:28:30 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 876B146B38; Tue, 22 Jul 2014 19:28:29 -0400 (EDT) Date: Wed, 23 Jul 2014 00:28:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Shawn Webb Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch In-Reply-To: <20140720201858.GB29618@pwnie.vrt.sourcefire.com> Message-ID: References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: PaX Team , Pedro Giffuni , Oliver Pinter , Bryan Drewery , freebsd-arch@freebsd.org 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: Tue, 22 Jul 2014 23:28:31 -0000 On Sun, 20 Jul 2014, Shawn Webb wrote: >> - It is yet undetermined what the performance effect will be, and it is not >> clear (but seems likely from past measurements) if there will be a >> performance hit even when ASLR is off. -Apparently there are applications >> that will segfault (?). > > So I have an old Dell Latitude E6500 that I bought at Defcon a year or > so ago that I'm doing testing on. Even though it's quite an underpowered > laptop, I'm running ZFS on it for BE support (in case one of our changes > kills it). I'll run unixbench on it a few times to benchmark the ASLR > patch. I'll test these three scenarios: > 1) ASLR compiled in and enabled; > 2) ASLR compiled in and disabled; > 3) ASLR compiled out (GENERIC kernel). > > In each of these three scenarios, I'll have the kernel debugging features > (WITNESS, INVARIANTS, etc.) turned off to better simulate a production > system and to remove just one more variable in the tests. > > I'll run unixbench ten times under each scenario and I'll compute averages. > > Since this is an older laptop (and it's running ZFS), these tests will take > a couple days. I'll have an answer for you soon. Hi Shawn: Great news that this work is coming to fruition -- ASLR is long overdue. Are you having any luck with performance measurements? Unixbench seems like a good starting point, but I wonder if it would be useful to look, in particular, at memory-mapping intensive workloads that might be affected as a result of changes in kernel VM data-structure use, or greater fragmentation of the address space. I'm not sure I have a specific application here in mind -- in the past I might have pointed out tools such as ElectricFence that tend to increase fragmentation themselves. Also, could you say a little more about the effects that the change might have on transparent superpage use -- other than suitable alignment of large mappings, it's not clear to me what effect it might have. I wonder if some equipment in the FreeBSD Netperf cluster might be used to help with performance characterisation -- in particular, very recent high-end server hardware, and also, lower-end embedded-style systems that have markedly different virtual-memory implementations in hardware and software. Often those two classes of systems see markedly different performance-change characteristics as a result of greater cache-centrism and instruction-level parallelism in the higher-end designs that can mask increases in instruction count. I think someone has already commented that Peter Holm's help might be enlisted; you have have seen his 'stress2' suite, which could help with stability testing. Thanks, Robert