grsecurity forums

Dear,
when I was studying pax in debian-ppc64 system(kernel-3.16.7, pax-linux-3.16.7-test12.patch), there are several questions not clear want to ask:
1. pax Is a stable or test version in powerpc
2. is paxtest have 64 bit version
3. Contrast X86 and PowerPC arch I found some features are not available. such as pax_open_kernel()/pax_close_kernel().are there other function not implemented in powerpc version?
4. when I was test paxctl,
# paxctl -C /usr/bin/vi
file /usr/bin/vi cannot have a PT_PAX_FLAGS program header, creation failed
#paxctl -C /bin/ls
#paxctl -c /bin/ls
#paxctl -v /bin/ls
PaX control v0.9
Copyright 2004,2005,2006,2007,2009,2010,2011,2012,2014 PaX Team <pageexec@freemail.hu>

- PaX flags: -------x-e-- [/bin/ls]
RANDEXEC is disabled
EMUTRAMP is disabled
why vi failed, ls is success?

lynliuyan wrote:1. pax Is a stable or test version in powerpc

well, we haven't distuingished between stable/test versions since the upstream kernel stopped doing so after 2.4, so as i tend to put it, we're in permanent test mode . that said, we do have long term supported series that one may call 'stable' in a sense. as for arch support, ppc has never received much love due to lack of hardware and user interest, so i'd definitely call it a 'test' version if you really need to label it .

2. is paxtest have 64 bit version

some of paxtest is arch specific, not bitness specific. spender's version of paxtest does have ppc support (both ppc32 and ppc64).

3. Contrast X86 and PowerPC arch I found some features are not available. such as pax_open_kernel()/pax_close_kernel().are there other function not implemented in powerpc version?

it's about features, not individual functions and no, ppc doesn't have all the features we have on x86, especially not the kernel self-protection features such as KERNEXEC, UDEREF, some of the gcc plugin based features, etc.

4. when I was test paxctl,
# paxctl -C /usr/bin/vi
file /usr/bin/vi cannot have a PT_PAX_FLAGS program header, creation failed

well, you have the source code so you can debug paxctl to see which condition fails . look at paxctl-elf.c:elf32_modify_phdr and in particular the checks at around lines 148-154. you can also compare the output of readelf -eW for both ls and vi and spot the difference. note that using -C is a last resort, you should really either recompile your binaries with a patched toolchain or use -c if GNU_STACK is present (or use grsec/RBAC to control the flags).

When I compile and test pax(kernel-3.16.7,pax-linux-3.16.7-test12.patch ) in debian-ppc64 OS, fangd two problems:
1. open CONFIG_PAX_LATENT_ENTROPY compiler option，compile error.
CC arch/powerpc/kernel/prom_init.o
CALL arch/powerpc/kernel/prom_init_check.sh
Error: External symbol 'latent_entropy' referenced from prom_init.c
arch/powerpc/kernel/Makefile:165: recipe for target 'prom_init_check' failed
make[2]: *** [prom_init_check] Error 1
Makefile:961: recipe for target 'arch/powerpc/kernel' failed
make[1]: *** [arch/powerpc/kernel] Error 2
make[1]: Leaving directory '/root/linux_3.16.7/grsecurity-test/linux-3.16.7'
debian/ruleset/targets/common.mk:295: recipe for target 'debian/stamp/build/kernel' failed
make: *** [debian/stamp/build/kernel] Error 2


2. open CONFIG_PAX_USERCOPY compiler option, replace the new kernel and reboot, panic.
[ 0.355328] Freeing unused kernel memory: 960K (c000000000a20000 - c000000000b10000)
-------------------------------------------error begin-------------------------------------------------
[ 0.355517] PAX: kernel memory leak attempt detected from c00000003682f650 (thread_info) (416 bytes)
[ 0.355522] CPU: 0 PID: 1 Comm: init Not tainted 3.16.7-pax #3
[ 0.355525] Call Trace:
[ 0.355529] [c00000003682f3e0] [c0000000000170a0] .show_stack+0x170/0x290 (unreliable)
[ 0.355535] [c00000003682f4d0] [c000000000803018] .dump_stack+0x88/0xb4
[ 0.355540] [c00000003682f550] [c0000000002aa83c] .__check_object_size+0xbc/0xe0
[ 0.355545] [c00000003682f5e0] [c000000000801b34] .create_elf_tables+0x60c/0x6c8
[ 0.355550] [c00000003682f890] [c00000000031676c] .load_elf_binary+0x10fc/0x18b0
[ 0.355554] [c00000003682f9e0] [c0000000002aa5ec] .search_binary_handler+0xec/0x280
[ 0.355559] [c00000003682fa90] [c000000000313ae8] .load_script+0x2a8/0x2e0
[ 0.355563] [c00000003682fba0] [c0000000002aa5ec] .search_binary_handler+0xec/0x280
[ 0.355567] [c00000003682fc50] [c0000000002ab4d0] .do_execve_common.isra.19+0x560/0x7a0
[ 0.355571] [c00000003682fd30] [c00000000000bf88] .run_init_process+0x48/0x70
[ 0.355575] [c00000003682fdb0] [c00000000000ca04] .kernel_init+0x64/0x140
[ 0.355579] [c00000003682fe30] [c00000000000a56c] .ret_from_kernel_thread+0x58/0x6c
[ 0.355641] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

first of all, you should be using a kernel version we support, 3.16 is too old and we no longer track it. that said, here's my first attempt at fixing the LATENT_ENTROPY problem, it will probably apply to 3.16 as well:

Code: Select all

--- a/arch/powerpc/kernel/Makefile  2014-12-08 21:49:18.036786841 +0100
+++ b/arch/powerpc/kernel/Makefile        2015-03-06 13:27:55.477666927 +0100
@@ -15,6 +15,11 @@
 CFLAGS_btext.o         += -fPIC
 endif

+CFLAGS_REMOVE_cputable.o = $(LATENT_ENTROPY_PLUGIN_CFLAGS)
+CFLAGS_REMOVE_prom_init.o = $(LATENT_ENTROPY_PLUGIN_CFLAGS)
+CFLAGS_REMOVE_btext.o = $(LATENT_ENTROPY_PLUGIN_CFLAGS)
+CFLAGS_REMOVE_prom.o = $(LATENT_ENTROPY_PLUGIN_CFLAGS)
+
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
 CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog

let me know if it works .

as for the second issue, can you try this patch please:

Code: Select all

--- a/kernel/fork.c     2015-03-02 00:14:36.285623129 +0100
+++ b/kernel/fork.c       2015-03-06 13:47:46.317603346 +0100
@@ -177,7 +177,7 @@
 void thread_info_cache_init(void)
 {
        thread_info_cache = kmem_cache_create("thread_info", THREAD_SIZE,
-                                             THREAD_SIZE, 0, NULL);
+                                             THREAD_SIZE, SLAB_USERCOPY, NULL);
        BUG_ON(thread_info_cache == NULL);
 }
 # endif

because Debian 8 use kernel-3.16, I was alse choose3.16
when I was compiled kernel code, compiler error（if '#cp include/linux/compiler.h arch/powerpc/boot/', the error disappear）
BOOTCC arch/powerpc/boot/gunzip_util.o
In file included from arch/powerpc/boot/gunzip_util.h:13:0,
from arch/powerpc/boot/gunzip_util.c:15:
arch/powerpc/boot/zlib.h:34:22: fatal error: compiler.h: No such file or directory
#include "compiler.h"
^
compilation terminated.
arch/powerpc/boot/Makefile:176: recipe for target 'arch/powerpc/boot/gunzip_util.o' failed
make[2]: *** [arch/powerpc/boot/gunzip_util.o] Error 1
arch/powerpc/Makefile:260: recipe for target 'zImage' failed
make[1]: *** [zImage] Error 2

does a vanilla kernel (without any patches) compile? also just because debian went with a certain kernel version doesn't mean that other kernels would not work, so you should still give 3.19 a try...

Is vanilla kernel, the problem only at powerpc version, x86 arch is correct.

Thank you for your answers!