Re: [PATCH] randomized mmap

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 05/30/05

  • Next message: Bruce Evans: "Re: [RFC] remove bus_memio.h and bus_pio.h" 
    Date: Mon, 30 May 2005 09:46:28 +0100 (BST)
To: Suleiman Souhlal <ssouhlal@FreeBSD.org>

    On Sun, 29 May 2005, Suleiman Souhlal wrote:

    > The patch at http://people.freebsd.org/~ssouhlal/testing/
    > mmap_random-20050528.diff implements random mmap addresses (unless of
    > course MAP_FIXED is being used), again from OpenBSD. This behavior can
    > be disabled setting the vm.mmap_random sysctl to 0. I think this could
    > greatly increase memory fragmentation, so I'm not sure it would be such
    > a good idea to have it on by default. Also, it doesn't really make
    > attacks unfeasable, but the implementation is so simple that I don't
    > think we really lose anything by letting users decide if they want to
    > enable it or not.

    Presumably the goal of this change is to make it harder to work around
    stack gap randomization, lack of execute bit on pages where code can be
    injected via data, etc by setting the return address in the overflowed
    buffer to a well-known address in a library rather than code injected into
    the stack?

    On a 32-bit system, this sort of change would be disastrous in terms of
    address space fragmentation, I would think. However, on a 64-bit system,
    it might be quite a bit less so. However, I'm not sure I'd implement it
    this way: in a 64-bit address space, we may want to do a bit more
    structuring of the address space and set aside a specific region for
    mmap's. Does it make sense to do the randomization only for mappings with
    the executable bit set, or implicitly set, when talking about 64-bit
    architectures that have a more reasonable notion of executable than i386?

    Were you aware that procfs has a 'map' feature that allows you to see what
    the practical effect of policy chnages in address space have on processes
    is? You might want to experiment a bit and see what the practical impact
    of maximum mapping is after loading a few shared libraries (etc) with this
    policy in place. If it turns out that, after 40 shared libraries are
    mapped into an address space, the process can no longer mmap more than a
    few megs, I'd definitely vote against it being included. Konqueror, btw,
    maps about 40 shared libraries by default on my notebook :-).

    How was the adjustment value of 256k selected, btw?

    Robert N M Watson
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Bruce Evans: "Re: [RFC] remove bus_memio.h and bus_pio.h"

    Relevant Pages