grsecurity forums

Hi!

(sorry for faults in my not native english)

Currently I'm running grsecurity (with PAX) on almost all servers (i386 and amd64) where I work or I assist with excellent results, I had yet to test it on some old sparc32/sparc64.

However, recently with the ever increasing global trend to put Linux on embedded devices, specially ARM and MIPS architectures and it's inherent increased need for protection I was wondering how complete is it's support in grsecurity and PAX?

I'm proficient in generating updated firmwares for embedded devices using the excellent OpenWRT embedded distribution so I'm planning to add hardening support with optional grsecurity/PAX to it and commit this work upstream so other embedded developers can benefit too.

I have 2 different ARMEL devices and other 2 different MIPS32 devices where I can test if you feed me with patches.

Thank you.

solca wrote:However, recently with the ever increasing global trend to put Linux on embedded devices, specially ARM and MIPS architectures and it's inherent increased need for protection I was wondering how complete is it's support in grsecurity and PAX?

grsec itself probably doesn't need any arch specific support code (unless there's something special to care about in /proc and similar), however most features in PaX are quite arch specific. some time ago i enabled ASLR support on both ARM and MIPS, but i don't know if they work as intended, so you can start by testing them . for non-exec pages support, it's a mixed bag. many of these CPUs don't have any capability for non-exec support, not even a split TLB to play with, so i'm afraid they'll be never supported. some variants however do have some or complete NX support (e.g., ARM v6 or MIPS 4KS with XI/RI), but since i lack hw access, i couldn't really develop anything so far. i know that there's interest to put at least the MIPS XI support into linux, but i have no idea where ARM v6 support stands.

PaX Team wrote:grsec itself probably doesn't need any arch specific support code (unless there's something special to care about in /proc and similar),

Excellent, I presume that.

PaX Team wrote:however most features in PaX are quite arch specific. some time ago i enabled ASLR support on both ARM and MIPS, but i don't know if they work as intended, so you can start by testing them .

I test for MIPS32 which seems more promising in the PAX patch than ARM, I'm pretty sure many more options in the Security section should be present when configuring the kernel as per reviewing the patch but for some reason just PAX_MEMORY_SANITIZE shows, then the compiling dies early at:

CC arch/mips/kernel/process.o
arch/mips/kernel/process.c:472: error: expected identifier or '(' before 'unsigned'

PaX Team wrote:for non-exec pages support, it's a mixed bag. many of these CPUs don't have any capability for non-exec support, not even a split TLB to play with, so i'm afraid they'll be never supported. some variants however do have some or complete NX support (e.g., ARM v6 or MIPS 4KS with XI/RI), but since i lack hw access, i couldn't really develop anything so far. i know that there's interest to put at least the MIPS XI support into linux, but i have no idea where ARM v6 support stands.

I don't know if latest QEMU is an initial option for the lack of hardware access but it's latest versions supports some ARM variants (including v6) and MIPS. The problem with small devices is that normally there's no room for toolchains and the change of kernels normally requires flashing the device. That why QEMU is invaluable because you can create big virtual disks, install something sane (like Debian) and test there. Anyway my dirty'n cheap home devices are ready for the flashing.

solca wrote:I test for MIPS32 which seems more promising in the PAX patch than ARM, I'm pretty sure many more options in the Security section should be present when configuring the kernel as per reviewing the patch but for some reason just PAX_MEMORY_SANITIZE shows,

that's weird, what's your CPU type set to? maybe the MIPS32/MIPS64 dependency should simply become MIPS?

then the compiling dies early at:

CC arch/mips/kernel/process.o
arch/mips/kernel/process.c:472: error: expected identifier or '(' before 'unsigned'

can you try the latest test patch to see if it's fixed?

I don't know if latest QEMU is an initial option for the lack of hardware access but it's latest versions supports some ARM variants (including v6) and MIPS. The problem with small devices is that normally there's no room for toolchains and the change of kernels normally requires flashing the device. That why QEMU is invaluable because you can create big virtual disks, install something sane (like Debian) and test there. Anyway my dirty'n cheap home devices are ready for the flashing.

i should have mentioned that lack of hw isn't the worst problem, lack of time is , so don't expect much progress besides what can be trivially supported (like ASLR).