Venkat Manakkal wrote: > I'm having trouble getting the latest hardened kernel and loop-aes happy with > each other, I've used older hardened kernels before. I suspect it is over > ambitious lockdown of PaX and GrSecurity. Sorry for late answer. I was busy. Looks like that CONFIG_PAX_KERNEXEC=y is what makes kernel enforce executable-or-writable-but-not-both for kernel space bits (which is good), but unfortunately it also makes executable kernel segments unreadable using normal read access (which is bad). Failing access is normal data read of executable '.text' section when assembler implementation of AES (aes-x86.S) key setup code attempts to access precomputed read-only data tables. This can be fixed by putting those precomputed tables in read-only-data '.rodata' section. But why were those precomputed tables put to '.text' section? Because at the time (year 2001) I intentionally made that assembler implementation work with many operating systems, including Linux, FreeBSD, and OpenBSD. The assembler in OpenBSD was prehistoric (binutils-1.x, man page from year 1991), and it failed to assemble that read-only-data section. So I worked around that incompatibility by putting those precomputed tables to read-only '.text' section. As of this writing, I don't know if grsec's executable but unreadable kernel space segments is a bug or intentionally sacrificed functionality to gain executable-or-writable-but-not-both for kernel space. A patch that puts loop-AES' precomputed tables in read-only-data '.rodata' section is below. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD --- ../loop-AES-v3.1c/aes-x86.S 2004-06-12 17:31:41.000000000 +0300 +++ ./aes-x86.S 2006-02-22 14:22:34.000000000 +0200 @@ -718,6 +718,7 @@ // // Here is precomputed output (it's more portable this way): + .section .rodata .align ALIGN32BYTES aes_rcon_tab: .long 0x01,0x02,0x04,0x08,0x10,0x20,0x40,0x80 - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
