From owner-svn-doc-head@freebsd.org Fri Jul 8 17:13:41 2016 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D585B845E2; Fri, 8 Jul 2016 17:13:41 +0000 (UTC) (envelope-from dru@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AAC01AFD; Fri, 8 Jul 2016 17:13:41 +0000 (UTC) (envelope-from dru@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u68HDeAS079076; Fri, 8 Jul 2016 17:13:40 GMT (envelope-from dru@FreeBSD.org) Received: (from dru@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u68HDedd079075; Fri, 8 Jul 2016 17:13:40 GMT (envelope-from dru@FreeBSD.org) Message-Id: <201607081713.u68HDedd079075@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: dru set sender to dru@FreeBSD.org using -f From: Dru Lavigne Date: Fri, 8 Jul 2016 17:13:40 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r49072 - head/en_US.ISO8859-1/htdocs/news/status X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:13:41 -0000 Author: dru Date: Fri Jul 8 17:13:40 2016 New Revision: 49072 URL: https://svnweb.freebsd.org/changeset/doc/49072 Log: Add ASLR report from kib@FreeBSD.org. Approved by: wblock Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml Fri Jul 8 16:33:41 2016 (r49071) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml Fri Jul 8 17:13:40 2016 (r49072) @@ -887,4 +887,148 @@ the update progress.

+ + + ASLR Interim State + + + + + Konstantin + Belousov + + kib@FreeBSD.org + + + + + Patch home + + + +

This is an interim report on the technical state of the ASLR + patch.

+ +

The proccontrol(1) utility was written to manage and + query ASLR enforcement on a per-process basis. It is required + for analyzing ASLR failures in specific programs. This + utility leverages the procctl(2) interface which was + added to the previous version of the patch, with some bug + fixes.

+ +

With r300792, ASLR settings are reset to system-wide defaults + whenever a setuid binary is executed.

+ +

The command's syntax is:

+ +

proccontrol -m (trace|aslr) [-q] [-s (enable|disable)] + [-p pid | command]

+ +

-m (specifies trace mode to control debugger + attachments)

+ +

-q (queries the state of the specified mode for the + process with the PID specified by -p option)

+ +

-e (toggles the feature on or off for the given + process or itself)

+ +

If the command is specified, it inherits the applied + settings from proccontrol. For instance, to start a + build of a program with ASLR disabled, use + proccontrol -m aslr -s disable make.

+ +

The ports exp run was done with ASLR tuned up to the most + aggressive settings. The results can be found in PR 208580.

+ +

SBCL is an interesting case which illustrates several points. + It is much smaller than JDK, and its build system is easier to + work with. The code provides a very non C-ish language + runtime which utilizes a lot of corner cases and non-standard + uses of VM, at least from the point of view of a typical C + programmer.

+ +

SBCL compiles Lisp forms into the machine native code and + manages its own arena for objects. The precompiled Lisp + runtime is mapped from the core file. SBCL relies on + the operating system's C runtime for the initial load of Lisp, + and needs a functional libc to issue many system + calls, including syscalls, as well as the dynamic loader. The + end result is that there are unfixed mmap(2) calls + during both startup and runtime, interfering with the + MAP_FIXED mmaps. The core file loading and arenas + are hard-coded to exist at fixed addresses.

+ +

This happens to work on the default address map, which is not + changed often, so the SBCL choices of the base addresses + evolved to work. But any significant distortion of the + standard map results in SBCL mmap(MAP_FIXED) requests + to override memory from other allocators.

+ +

&os; uses the MAP_EXCL flag to mmap(2), + which must be used in MAP_FIXED|MAP_EXCL form to + cause mmap(2) failure if the requested range is + already used. I tried to force MAP_FIXED requests + from SBCL to implicitely set MAP_EXCL, but this did + not go well since SBCL sometimes pre-allocates regions for + later use with MAP_FIXED. So, MAP_EXCL + mappings failed, dumping the process into ldb.

+ +

On Linux, if a kernel is detected in AS-randomization mode, + the initial SBCL runtime sets personality to non-random and + re-execs. This might be a solution for &os; as well, after + the ASLR patch is committed, so that the procctl(2) + knob is officially available.

+ +

SBCL still has issues on Linux, even with re-exec, when + more aggressive randomization from PaX patch is applied, as + seen in bug + 1523213.

+ +

The Emacs build procedure involves loading the + temacs image with the compiled Emacs Lisp files and + then dumping the memory to recreate the image with the + preloaded content, in order to shrink the start time.

+ +

Recent Emacs sources seem to generally avoid + MAP_FIXED, except in some situations. When Emacs + does use the flag, it carefully checks that the selected + region is not busy. In fact, Emacs would benefit from + MAP_EXCL.

+ +

I tried several runs of building Emacs and running the dumped + binary, but was not able to reproduce the issue. It seems + that the code improved enough to tolerate ASLR both in Linux + and NetBSD without turning it off.

+ +

In my opinion, it is not reasonable to fight the issues in + the kernel as most of it is not fixable from the kernel side. + The procctl(2) interface and proccontrol(1) + utilities provide the override when needed, but are not + automated.

+ +

The set of ports which cannot be built with ASLR turned on + should be limited but fluid. However, exp-runs may not + reliably uncover all problems due to randomization, as seen in + the Emacs example. In the route to enable ASLR by default in + non-aggressive settings, the ports framework should provide an + option like ASLR_UNSAFE=yes which spawns + proccontrol -m aslr -s disable make for the build + stages of the unsafe port. Users would still need to be aware + of proccontrol(1) in order to run the resulting + binary.

+ +

A recommended approach is a flag in the ELF binary to mark + it as not compatible with non-standard AS layouts. This frees + users from having to use proccontrol(1), but still + requires patching and upstreaming. This approach is also + useful outside the context of ASLR. However, the + mechanism is not yet ready, and developing it is a larger work + than ASLR itself.

+ + + The FreeBSD Foundation +