svn commit: r320430 - head/sys/vm

[Shawn Webb]

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?

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20170629/2c576b36/attachment.sig>