Date: Sat, 16 Apr 2016 23:20:51 +0000 (UTC) From: Warren Block <wblock@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48656 - head/en_US.ISO8859-1/htdocs/news/status Message-ID: <201604162320.u3GNKp7q070657@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: wblock Date: Sat Apr 16 23:20:51 2016 New Revision: 48656 URL: https://svnweb.freebsd.org/changeset/doc/48656 Log: General editing and markup additions. Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml Sat Apr 16 19:50:04 2016 (r48655) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml Sat Apr 16 23:20:51 2016 (r48656) @@ -350,7 +350,7 @@ <given>Jared</given> <common>McNeill</common> </name> - <email>jmcneill@freebsd.org</email> + <email>jmcneill@FreeBSD.org</email> </person> <person> @@ -770,14 +770,14 @@ </contact> <body> - <p>POSIX specifies several kinds of pthread locks, for this - report the private and process-shared variants are considered. + <p>POSIX specifies several kinds of <tt>pthread</tt> locks. For this + report, the private and process-shared variants are considered. Private locks can be used only by the threads of the same process, which share the address space. Process-shared locks can be used by threads from any process, assuming the process can map the lock memory into its address space.</p> - <p>Our libthr, the library implementing the POSIX threads and + <p>Our <tt>libthr</tt>, the library implementing the POSIX threads and locking operations, uses a pointer as the internal representation behind a lock. The pointer contains the address of the actual structure carrying the lock. This has @@ -787,11 +787,11 @@ distinct address spaces.</p> <p>A common opinion was that we have no choice but to break the - libthr Application Binary Interface (ABI) by changing the lock + <tt>libthr</tt> Application Binary Interface (ABI) by changing the lock types to be the actual lock structures (and padding for future ABI extension). This is very painful for users, as our - previous experience with non-versioned libc and libc_r - shown.</p> + previous experience with non-versioned <tt>libc</tt> and <tt>libc_r</tt> + has shown.</p> <p>Instead, I proposed and implemented a scheme where process-shared locks can be implemented without breaking the @@ -799,13 +799,13 @@ hash of the shared memory objects (off-pages), which carry the real lock structures.</p> - <p>New umtx operations to create or look up the shared object, - by the memory key, were added. Libthr is modified to lookup + <p>New <tt>umtx</tt> operations to create or look up the shared object, + by the memory key were added. <tt>libthr</tt> is modified to look up the object and use it for shared locks, instead of using - malloc() as for private locks.</p> + <tt>malloc()</tt> as for private locks.</p> <p>The pointer value in the user-visible lock type contains a - canary for shared locks. Libthr detects the canary and + canary for shared locks. <tt>libthr</tt> detects the canary and switches into the shared-lock mode.</p> <p>The proposal of inlining the lock structures, besides the @@ -814,16 +814,16 @@ important advantage over the off-page page approach is that no off-page object needs to be maintained, and the lifecycle of the shared lock naturally finishes with the destruction of the - shared memory, without explicit cleanup. Right now, off-pages - hook into vm object termination to avoid leakage, but long - liviness of the vnode vm object prolonges the off-page + shared memory without explicit cleanup. Right now, off-pages + hook into vm object termination to avoid leakage, but + long-livedness of the vnode vm object prolonges the off-page existence for shared locks backed by files, however unlikely they may be.</p> - <p>Libthr with inlined locks become informally known as libthr2 - project, since the library name better be changed instead of - only bumping the library version. The rtld should ensure that - libthr and libthr2 do not become simultaneously loaded into a + <p><tt>libthr</tt> with inlined locks became informally known as the <tt>libthr2</tt> + project, since it is better to change the library name than just + bumping the library version. <tt>rtld</tt> should ensure that + <tt>libthr</tt> and <tt>libthr2</tt> are not simultaneously loaded into a single address space.</p> </body> @@ -835,17 +835,17 @@ </task> <task> - <p>Evaluate and implement libthr2.</p> + <p>Evaluate and implement <tt>libthr2</tt>.</p> </task> </help> </project> <project cat='team'> - <title>Clusteradm</title> + <title>Cluster Admin</title> <contact> <person> - <email>clusteradm@freebsd.org</email> + <email>clusteradm@FreeBSD.org</email> </person> </contact> @@ -856,7 +856,7 @@ <li>migrated services out of the hosting space in ISC (peter, sbruno)</li> - <li>begun migration of services into RootBSD hosting space + <li>began migration of services into RootBSD hosting space (peter, sbruno)</li> <li>collaborated with phabricator admin team to migrate to @@ -1079,7 +1079,7 @@ <given>Justin</given> <common>Hibbits</common> </name> - <email>jhibbits@freebsd.org</email> + <email>jhibbits@FreeBSD.org</email> </person> </contact> @@ -1309,7 +1309,7 @@ <given>Hans Petter</given> <common>Selasky</common> </name> - <email>hselasky@freebsd.org</email> + <email>hselasky@FreeBSD.org</email> </person> </contact> @@ -1600,20 +1600,22 @@ </contact> <links> - <url href="https://kib.kiev.ua/kib/aslr">Patch home.</url> + <url href="https://kib.kiev.ua/kib/aslr">Patch home</url> + <url href="https://www.kib.kiev.ua/kib/aslr/paxtest.log"><tt>paxtest.log</tt></url>; + <url href="https://www.kib.kiev.ua/kib/aslr/fedora.log"><tt>fedora.log</tt></url>; </links> <body> <p>I wrote a small and straightforward yet feature-packed patch - to implement ASLR for &os; available for broader testing.</p> + to implement ASLR for &os; which is now available for broader testing.</p> <p>With this change, randomization is applied to all non-fixed mappings. By randomization I mean the base address for the mapping is selected with a guaranteed amount of entropy (bits). If the mapping was requested to be superpage aligned, - the randomization honours the superpage attributes.</p> + the randomization honors the superpage attributes.</p> - <p>The randomization is done on a best-effort basis - that is, + <p>The randomization is done on a best-effort basis. That is, the allocator falls back to a first fit strategy if fragmentation prevents entropy injection. It is trivial to implement a strong mode where failure to guarantee the @@ -1623,43 +1625,43 @@ <p>I have not fine-tuned the amount of entropy injected right now. It is only a quantitive change that will not change the implementation. The current amount is controlled by - aslr_pages_rnd.</p> + <tt>aslr_pages_rnd</tt>.</p> <p>To not spoil coalescing optimizations, to reduce the page table fragmentation inherent to ASLR, and to keep the - transient superpage promotion for the malloced memory, the + transient superpage promotion for the <tt>malloc</tt>ed memory, the locality is implemented for anonymous private mappings, which are automatically grouped until fragmentation kicks in. The initial location for the anon group range is, of course, randomized. After some additional tuning, the measures - appeared to be quite effective. In particular, very - address-space hungry build of PyPy 5.0 on i386 successfully + appeared to be quite effective. In particular, a very + address-space-hungry build of PyPy 5.0 on i386 successfully finished with the most aggressive functionality of the patch activated.</p> - <p>The default mode keeps the sbrk area unpopulated by other + <p>The default mode keeps the <tt>sbrk</tt> area unpopulated by other mappings, but this can be turned off, which gives much more breathing bits on the small AS architectures (funny that - 32bits is considered small). This is tied with the question + 32 bits is considered small). This is tied with the question of following an application's hint about the <tt>mmap(2)</tt> base address. Testing shows that ignoring the hint does not affect the function of common applications, but I would expect - more demanding code could break. By default sbrk is preserved - and mmap hints are satisfied, which can be changed by using - the kern.elf{32,64}.aslr_care_sbrk sysctl (currently enabled + more demanding code could break. By default <tt>sbrk</tt> is preserved + and <tt>mmap</tt> hints are satisfied, which can be changed by using + the <tt>kern.elf{32,64}.aslr_care_sbrk</tt> sysctl (currently enabled by default for wider testing).</p> <p>Stack gap, W^X, shared page randomization, KASLR and other techniques are explicitly out of scope of this work.</p> - <p>The paxtest results for the run with the previous version 5 - of the patch applied and aggresively tuned can be seen at the - https://www.kib.kiev.ua/kib/aslr/paxtest.log . For + <p>The <tt>paxtest</tt> results for the run with the previous version 5 + of the patch applied and aggressively tuned can be seen at + <a href="https://www.kib.kiev.ua/kib/aslr/paxtest.log"><tt>paxtest.log</tt></a>. For comparison, the run on Fedora 23 on the same machine is at - https://www.kib.kiev.ua/kib/aslr/fedora.log .</p> + <a href="https://www.kib.kiev.ua/kib/aslr/fedora.log"><tt>fedora.log</tt></a>.</p>; - <p>ASLR is enabled on per-ABI basis, and currently it is only - enabled on native i386 and amd64 (including compat 32bit) and + <p>ASLR is enabled on a per-ABI basis, and currently is only + enabled on native i386 and amd64 (including compat 32-bit) and ARMv6 ABIs. I expect to test and enable ASLR for arm64 as well, later.</p> @@ -1667,7 +1669,7 @@ I have not provided a userspace wrapper around the syscall. In fact, the most reasonable control needed is per-image and not per-process, but we have no tradition to put the - kernel-read attributes into the extattrs of binary, so I am + kernel-read attributes into the extattrs of a binary, so I am still pondering that part and this also explains the non-written tool.</p> @@ -1680,7 +1682,7 @@ Foundation for directing me.</p> <p>Bartek Rutkowski tested PyPy builds on i386, and David Naylor - helped with the port which was at point of turbulence and + helped with the port which was at the point of turbulence and upgrade during the work.</p> </body>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201604162320.u3GNKp7q070657>