On Fri, Jul 31, 2015 at 12:28 AM, Maxime Villard <m...@netbsd.org> wrote:
> Module Name: src
> Committed By: maxv
> Date: Thu Jul 30 15:28:18 UTC 2015
>
> Modified Files:
> src/sys/kern: exec_elf.c kern_pax.c
> src/sys/sys: exec_elf.h pax.h
>
> Log Message:
> Revamp PaX:
> - don't confuse between ELF flags and proc flags. Introduce the proc-
> specific P_PAX_ASLR, P_PAX_MPROTECT and P_PAX_GUARD flags.
> - introduce pax_setup_elf_flags(), which takes as argument the PaX flag
> of the ELF PaX note section, and which sets the proc flag as
> appropriate. Also introduce a couple of other functions used for that
> purpose.
> - modify pax_aslr_active(), and all the other similar pieces of code, so
> that it checks the proc flag directly, without extra ELF computation
>
> In addition to making PaX clearer, the combination of these changes fixes
> the following bug: if a non-PaX'ed process is launched, and then someone
> sets security.pax.{aslr,mprotect,segvguard}.global=1, the process becomes
> PaX'ed while its address space hasn't been randomized, which is not likely
> to be a good idea.
>
> Now, only the proc flag is checked at runtime, which means the process's
> PaX status won't be altered during the execution.
>
> Also:
> - declare PAX_DPRINTF, makes it more readable
> - fix a typo in exec_elf.h
http://releng.netbsd.org/b5reports/amd64/build/2015.07.30.21.47.51/test.html#lib_libc_sys_t_mprotect_mprotect_pax
http://releng.netbsd.org/b5reports/i386/build/2015.07.30.15.29.52/test.html#lib_libc_sys_t_mprotect_mprotect_pax
It seems that the change adds a new failure on amd64/i386.
Any ideas?
Regards,
ozaki-r
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.72 -r1.73 src/sys/kern/exec_elf.c
> cvs rdiff -u -r1.28 -r1.29 src/sys/kern/kern_pax.c
> cvs rdiff -u -r1.148 -r1.149 src/sys/sys/exec_elf.h
> cvs rdiff -u -r1.11 -r1.12 src/sys/sys/pax.h
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
