svn commit: r320430 - head/sys/vm

[Pedro Giffuni]

Hello;

On 6/29/2017 8:23 AM, Shawn Webb wrote:
> On Wed, Jun 28, 2017 at 06:32:38PM -0400, Shawn Webb wrote:
>> On Wed, Jun 28, 2017 at 04:02:37AM +0000, Konstantin Belousov wrote:
>>> Author: kib
>>> Date: Wed Jun 28 04:02:36 2017
>>> New Revision: 320430
>>> URL: https://svnweb.freebsd.org/changeset/base/320430
>>>
>>> Log:
>>>    Treat the addr argument for mmap(2) request without MAP_FIXED flag as
>>>    a hint.
>>>    
>>>    Right now, for non-fixed mmap(2) calls, addr is de-facto interpreted
>>>    as the absolute minimal address of the range where the mapping is
>>>    created.  The VA allocator only allocates in the range [addr,
>>>    VM_MAXUSER_ADDRESS].  This is too restrictive, the mmap(2) call might
>>>    unduly fail if there is no free addresses above addr but a lot of
>>>    usable space below it.
>>>    
>>>    Lift this implementation limitation by allocating VA in two passes.
>>>    First, try to allocate above addr, as before.  If that fails, do the
>>>    second pass with less restrictive constraints for the start of
>>>    allocation by specifying minimal allocation address at the max bss
>>>    end, if this limit is less than addr.
>>>    
>>>    One important case where this change makes a difference is the
>>>    allocation of the stacks for new threads in libthr.  Under some
>>>    configuration conditions, libthr tries to hint kernel to reuse the
>>>    main thread stack grow area for the new stacks.  This cannot work by
>>>    design now after grow area is converted to stack, and there is no
>>>    unallocated VA above the main stack.  Interpreting requested stack
>>>    base address as the hint provides compatibility with old libthr and
>>>    with (mis-)configured current libthr.
>>>    
>>>    Reviewed by:	alc
>>>    Tested by:	dim (previous version)
>>>    Sponsored by:	The FreeBSD Foundation
>>>    MFC after:	1 week
>>>
>>> Modified:
>>>    head/sys/vm/vm_map.c
>>>    head/sys/vm/vm_map.h
>>>    head/sys/vm/vm_mmap.c
>> Hey Kostik,
>>
>> This commit breaks both xorg and shutting down/rebooting. Reverting this
>> commit makes my laptop happy again.
> Thnking out loud: would these issues arise due to HardenedBSD using
> SafeStack, which relies on libthr's stack code?

I haven't been looking at SafeStack lately but unless HardenedBSD took 
the FreeBSD-specific code from EPFL and did some real work on it, there 
is little chance it does its work well.

Pedro.

ps. I would guess Oliver knows about the EPFL code since he did some 
review on github.