Date: Thu, 24 Jul 2014 10:43:31 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Tim Kientzle <tim@kientzle.com> Cc: Shawn Webb <lattera@gmail.com>, Oliver Pinter <oliver.pntr@gmail.com>, Pedro Giffuni <pfg@freebsd.org>, freebsd-arch@freebsd.org, PaX Team <pageexec@freemail.hu>, Bryan Drewery <bdrewery@freebsd.org> Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch Message-ID: <alpine.BSF.2.11.1407241035550.116@fledge.watson.org> In-Reply-To: <796EDB88-3768-48AA-B909-8A7FFBED0C1E@kientzle.com> References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <alpine.BSF.2.11.1407230017490.88645@fledge.watson.org> <20140723004543.GH29618@pwnie.vrt.sourcefire.com> <D7CEDB47-2818-461A-BB70-479BEBDCEEE9@freebsd.org> <796EDB88-3768-48AA-B909-8A7FFBED0C1E@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 Jul 2014, Tim Kientzle wrote: >>> 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. >> >> Somewhat related to ElectricFence… will ASLR have an adverse effect on >> debuggers? >> >> I googled around and got to this: >> >> http://www.outflux.net/blog/archives/2010/07/03/gdb-turns-off-aslr/ >> >> 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’m setting the breakpoint > will have the same meaning between runs. Non-determism in debugging is a big issue with diversification/randomisation-based mitigation techniques. There are a number of aspects to the problem, but the most clear implication is that it should be possible to create deterministic and reproducible debugging environments in the local development context. This means, I think, being able to create a hierarchy of processes in which the randomisation features are by policy turned off. The contexts in which that property is set are interesting -- do you want a "no randomisation subshell" in which every program you run has ASLR turned off? Or do you just want gdb to turn it off? What if, this time around, you want gdb to have it turned on? And how do you deal with setuid/setgid/transitioning binaries -- we don't want a regular user to say "turn off ASLR for this process subtree" and have it prevent ASLR from protecting a setuid binary from the user. I think the natural conclusion is that you need multiple means to disable ASLR that operate at different granularities, and that have different control mechanisms. Off-hand, I see a few: (1) A global enable/disable flag that sets the default policy. (2) A new inherited process property, or perhaps credential property, enabling ASLR. This can be changed to 'disabled' using a system call -- perhaps prctl() or similar. If we hit a transitioning binary (e.g., setuid) then in the same way that we manipulate other properties, we'd reset to the global default. It would be easy to imagine this being CR_ASLR on the cr_flags field of the credential. This could be set in various ways by userspace applications -- by gdb, as a login-shell property, perhaps via 'su' or something simular? (3) As suggested by Kostik, an ELF note on binaries indicating that the binary is not ASLR-compatible, which would override (I guess) the global policy flag and process/credential flag. We could then set this with NO_ASLR=true in Makefiles, during package creation, etc. (4) It sounds like a jail-scope policy would also be useful -- I guess this might actually be the same as (1) in the sense that (1) could be represented in terms of a jail-scope policy. I'm not opposed to MAC policy modules being able to manipulate ASLR behaviour, but I think I'd prefer that the core policy controls (e.g., the above) be MAC-independent. Part of the reason is that you may want ASLR on very low-end systems where the additional cost of MAC interposition is more measurable. How does this interact with features like the Linuxulator? Do we also want ABI emulations to be able to disable ASLR as ABIs might not support it [well]? Robert From owner-freebsd-arch@FreeBSD.ORG Thu Jul 24 09:49:55 2014 Return-Path: <owner-freebsd-arch@FreeBSD.ORG> 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 F2A4FDE2; Thu, 24 Jul 2014 09:49:54 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id CBFBD2BC8; Thu, 24 Jul 2014 09:49:54 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 87D8146B0D; Thu, 24 Jul 2014 05:49:53 -0400 (EDT) Date: Thu, 24 Jul 2014 10:49:53 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> X-X-Sender: robert@fledge.watson.org To: Adrian Chadd <adrian@freebsd.org> Subject: Re: [rfc] where to put cpuid_t ? In-Reply-To: <CAJ-VmokOpA8nFashcTpmU0j8Dyw_LX-VvVudcppuGyGV97PRbA@mail.gmail.com> Message-ID: <alpine.BSF.2.11.1407241045400.116@fledge.watson.org> References: <CAJ-VmokOpA8nFashcTpmU0j8Dyw_LX-VvVudcppuGyGV97PRbA@mail.gmail.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: "freebsd-arch@freebsd.org" <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 <freebsd-arch.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>; List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 24 Jul 2014 09:49:55 -0000 On Thu, 24 Jul 2014, Adrian Chadd wrote: > I've been chipping away at a cpuid_t in a local branch for a while and I > think I have the very basics working well enough. > > However, the most annoying thing that's crept up is the most bikeshed topic > of them all - where should it live. > > I'd like to avoid having to include sys/pcpu.h or sys/_cpuset.h just for the > id type - it seems a bit overkill. > > So - suggestions? Otherwise I'm going to leave it in sys/pcpu.h and just > polluate appropriately. > > I'd like to try and get cpuid_t and a handful of KBI-changing things into > -HEAD before 11 is branched so we at least have a hope of trying to support > > 128 CPUs out of the box in the immediate future and > 253 CPUs in the > later future. Sounds like bikeshed fodder. Usually you end up with widely used core types in _types.h or _foo.h, with some notion of publiciness being defined in types.h, param.h, or foo.h. I'd leave it where it is until you discover you need the header everywhere or nested all over the place, in which case I'd then shift it to a centralised header. At least for SRI and Cambridge, the ability to name a few hundred cores/threads is concern that will arise later this year. I'd like to see a CPU ID type that can represent >128 threads almost immediately -- ideally no less than 512 in the beginning of next year as hardware starts to come together. (In case anyone is wondering where we find such hardware: we use FPGA-based soft-core processors in our research, and are about to move from a single-FPGA platform which typically hosts a smallish numbers of cores and threads to a multi-FPGA platform which could lead to quite fast growth in core count, and also quite NUMAish properties. We can time-division multiplex core implementations on FPGAs leading to many more virtual than physical cores). Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.11.1407241035550.116>