hmm. I'm not a big fan of OpenBSD's randomization code. I'm not
rabidly against the patch but it is a bit hackish. It seems to me
that somthing similar could be implemented simply by having the RTLD
or LIBC code mmap() a randomly sized dead segment, and not have to
build anything into the kernel.

:> hmm. I'm not a big fan of OpenBSD's randomization code. I'm not
:> rabidly against the patch but it is a bit hackish. It seems to me
:> that somthing similar could be implemented simply by having the RTLD
:> or LIBC code mmap() a randomly sized dead segment, and not have to
:> build anything into the kernel.
:
:Wouldn't that result in 2x the syscalls for calling mmap()?(isn't this
:expensive?) Or do I not understand what you mean?
:
:-Kevink
:
:--
:Kevin L. Kane

You could just request more space then you need and randomly offset
the allocations you do from within that space. That has the same
result pretty much.

Or you could just make a few randomly-sized mmap() calls at the start
of the program but not on every mmap. The first few calls will offset
the address returned by all later calls.

Similarly you can create a random stack offset by allocating a random
amount of space on the stack at program start. There is no need to
have the kernel do it for you when you can do it yourself (libc, that is).

well, that's quite different. randomizing mmap offsets gives a real random distribution over the whole userland address space. allocating more and then offsetting within this allocation still gives a deterministic order of allocated memory locations, just the padding between those varies.

:well, that's quite different. randomizing mmap offsets gives a real random distribution over the whole userland address space. allocating more and then offsetting within this allocation still gives a deterministic order of allocated memory locations, just the padding between those varies.
:
:cheers
: simon

Randomizing mmap offsets that much will fragment user virtual memory
and cause the program to run out of space if it uses mmap() heavily.
I really dislike the concept.

I have to agree with Simon, doing as you suggest will reduce the
effectiveness of the concept(maybe to the point where its not worth
doing at all?) Obviously we shouldn't be wasteful but the benefit of
random distrobution here outweighs the memory costs.

Given other comments, I think you should put all the changed code under
an #ifdef, and add that to conf/options to be defined in file opt_vm.h
(e.g., VM_MMAPOFF_RANDOMIZE opt_vm.h), then include opt_vm.h in the
relevant files. Ofcourse, the option wouldn't be enabled by default, but
people who want security through obscurity can easily enable it at their
leasure in their kernel config, and recompile :).

it is not obscurity, but instead prevents the exploitation of any fixed memory offset in executables. it makes memory ordering basically so non-deterministic that it is close to impossible to craft a working exploit. in combination with W^X this creates a very very secure execution environment.

No matter how close-to-impossible it is to craft a working exploit,
technically it is still obcurity. Ofcourse I do agree with you that
given a large enough address space, this is a very powerful tool to
deter attackers (imagine groveling a 64bit virtual address space for the
hole you're looking for, I'll prefer to do other things with my time;
also, it's quite possible to construct an IDS which catches these
grovelings real quick). The chance of the attacker finding the hole
becomes so slim that, economically, it is not worth pursueing. However:
this does not change the fact that *technically*, it still is obscuring.

P.S.
If you wish to do so, read the IRC backlog; I had this discussion with
'tigger^' already :).

this I386_MAX_EXE_ADDR is only used for openbsd's W^X i386 implementation, I think. The code is not really complicated, so I think we should add it. However, I think that it should be optional to switch on via a sysctl. Putting everything in kernel options makes everything so... bulky. Of course this sysctl would need to be guarded by securelevel.

:Thomas had an earlier suggestion to make a kernel option, would that
:be a reasonable compromise, or would you still prefer it to be limited
:to libc?
:
:-Kevink
:
:--
:Kevin L. Kane
:kevin.kane at gmail.com

Well, I don't want to do anything for this release. Lets discuss it
again after the release. As I said, I am not against putting it in
the kernel, I'm just not happy with the side effects of doing so.