While here, don't make too much use of one random value, and call
arc4random() directly. Allows for the removal of 'ep_random' from the
exec_package.
Prompted by and okay christos@.
For regular (non PIE) executables randomization is enabled for:
1. The data segment
2. The stack
For PIE executables(*) randomization is enabled for:
1. The program itself
2. All shared libraries
3. The data segment
4. The stack
(*) To generate a PIE executable:
- compile everything with -fPIC
- link with -shared-libgcc -Wl,-pie
This feature is experimental, and might change. To use selectively add
options PAX_ASLR=0
in your kernel.
Currently we are using 12 bits for the stack, program, and data segment and
16 or 24 bits for mmap, depending on __LP64__.
avoid wasting OS flag bits. In the future we'll probably use fileassoc to
achieve this (once there is a way to make fileassoc persistent) or in the
shorter term libelf, so that we can add and remove the note on demand instead
of burning bits on each binary. Of course since this is a tool, this means
that we'll need to think about how to handle libelf...
fileassoc_table_add() was removed from the KPI and made internal. From now
fileassoc(9) will manage the optimal table size internally.
Input from and okay yamt@.
- make fileassoc_t a pointer and remove FILEASSOC_INVAL.
- clean up kern_fileassoc.c. unify duplicated code.
- unexport fileassoc_init using RUN_ONCE(9).
- plug memory leaks in fileassoc_file_delete and fileassoc_table_delete.
- always call callbacks, regardless of the value of the associated data.
ok'ed by elad.
code and not trying to use temporary solutions.
Lots of comments and help from YAMAMOTO Takashi, also thanks to the PaX
author for being quick to recognize that something fishy's going on. :)
Hook up in mmap/vmcmd rather than (ugh!) uvm_map_protect().
Next time I suggest to commit a temporary solution just revoke my
commit bit.
