svn commit: r320430 - head/sys/vm

[Shawn Webb]

On Thu, Jun 29, 2017 at 09:23:33AM -0400, 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?

Here's a somewhat crude and possibly improper fix that makes my laptop
happy: http://ix.io/y6z

I'm not sure, though, that really fixes the problem or just dances
around it.

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/f7facf54/attachment.sig>