Date: Fri, 8 Jul 2016 17:13:40 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> 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 Message-ID: <201607081713.u68HDedd079075@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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.</p> </body> </project> + + <project cat='proj'> + <title>ASLR Interim State</title> + + <contact> + <person> + <name> + <given>Konstantin</given> + <common>Belousov</common> + </name> + <email>kib@FreeBSD.org</email> + </person> + </contact> + + <links> + <url href="http://kib.kiev.ua/kib/aslr">Patch home</url> + </links> + + <body> + <p>This is an interim report on the technical state of the ASLR + patch.</p> + + <p>The <tt>proccontrol(1)</tt> 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 <tt>procctl(2)</tt> interface which was + added to the previous version of the patch, with some bug + fixes.</p> + + <p>With r300792, ASLR settings are reset to system-wide defaults + whenever a setuid binary is executed.</p> + + <p>The command's syntax is:</p> + + <p><tt>proccontrol -m (trace|aslr) [-q] [-s (enable|disable)] + [-p pid | command]</tt></p> + + <p><tt>-m</tt> (specifies trace mode to control debugger + attachments)</p> + + <p><tt>-q</tt> (queries the state of the specified mode for the + process with the PID specified by <tt>-p</tt> option)</p> + + <p><tt>-e</tt> (toggles the feature on or off for the given + process or itself)</p> + + <p>If the command is specified, it inherits the applied + settings from <tt>proccontrol</tt>. For instance, to start a + build of a program with ASLR disabled, use + <tt>proccontrol -m aslr -s disable make</tt>.</p> + + <p>The ports exp run was done with ASLR tuned up to the most + aggressive settings. The results can be found in <a + href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208580">PR 208580</a>.</p> + + <p>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.</p> + + <p>SBCL compiles Lisp forms into the machine native code and + manages its own arena for objects. The precompiled Lisp + runtime is mapped from the <tt>core</tt> file. SBCL relies on + the operating system's C runtime for the initial load of Lisp, + and needs a functional <tt>libc</tt> to issue many system + calls, including syscalls, as well as the dynamic loader. The + end result is that there are unfixed <tt>mmap(2)</tt> calls + during both startup and runtime, interfering with the + <tt>MAP_FIXED mmaps</tt>. The core file loading and arenas + are hard-coded to exist at fixed addresses.</p> + + <p>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 <tt>SBCL mmap(MAP_FIXED)</tt> requests + to override memory from other allocators.</p> + + <p>&os; uses the <tt>MAP_EXCL</tt> flag to <tt>mmap(2)</tt>, + which must be used in <tt>MAP_FIXED|MAP_EXCL</tt> form to + cause <tt>mmap(2)</tt> failure if the requested range is + already used. I tried to force <tt>MAP_FIXED</tt> requests + from SBCL to implicitely set <tt>MAP_EXCL</tt>, but this did + not go well since SBCL sometimes pre-allocates regions for + later use with <tt>MAP_FIXED</tt>. So, <tt>MAP_EXCL</tt> + mappings failed, dumping the process into <tt>ldb</tt>.</p> + + <p>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 <tt>procctl(2)</tt> + knob is officially available.</p> + + <p>SBCL still has issues on Linux, even with re-exec, when + more aggressive randomization from PaX patch is applied, as + seen in <a + href="https://bugs.launchpad.net/sbcl/+bug/1523213">bug + 1523213</a>.</p> + + <p>The Emacs build procedure involves loading the + <tt>temacs</tt> 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.</p> + + <p>Recent Emacs sources seem to generally avoid + <tt>MAP_FIXED</tt>, 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 + <tt>MAP_EXCL</tt>.</p> + + <p>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.</p> + + <p>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 <tt>procctl(2)</tt> interface and <tt>proccontrol(1)</tt> + utilities provide the override when needed, but are not + automated.</p> + + <p>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 <tt>ASLR_UNSAFE=yes</tt> which spawns + <tt>proccontrol -m aslr -s disable make</tt> for the build + stages of the unsafe port. Users would still need to be aware + of <tt>proccontrol(1)</tt> in order to run the resulting + binary.</p> + + <p>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 <tt>proccontrol(1)</tt>, 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.</p> + </body> + + <sponsor>The FreeBSD Foundation</sponsor> + </project> </report>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201607081713.u68HDedd079075>