paxtest tests not failing on kvm guest

[esanders83]

Good evening,

Been playing with grsec for years on baremetal and just spun up a new VM using proxmox/kvm.

Fresh copy of debian 7.8 and downloaded/compiled:
Kernel 3.2.66 (vanilla from kernel.org)
grsecurity-3.0-3.2.66-201502021851.patch

enabled grsec:
config method (automatic)
usage type (server)
Virtualization Type (guest)
Virtualization Software(KVM)
Required Priorities (Security)

when I run paxtest (0.9.13) after rebooting with new grsec kernel. most tests show vulnerable:
Mode: kiddie
Linux box01 3.2.66-grsec #1 SMP Tue Feb 3 15:15:14 CST 2015 x86_64 GNU/Linux

Executable anonymous mapping : Vulnerable
Executable bss : Vulnerable
Executable data : Vulnerable
Executable heap : Vulnerable
Executable stack : Killed
Executable shared library bss : Vulnerable
Executable shared library data : Vulnerable
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : Killed
Anonymous mapping randomisation test : 29 quality bits (guessed)
Heap randomisation test (ET_EXEC) : 22 quality bits (guessed)
Heap randomisation test (PIE) : 35 quality bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 27 quality bits (guessed)
Shared library randomisation test : 29 quality bits (guessed)
VDSO randomisation test : 29 quality bits (guessed)
Stack randomisation test (SEGMEXEC) : 35 quality bits (guessed)
Stack randomisation test (PAGEEXEC) : 35 quality bits (guessed)
Arg/env randomisation test (SEGMEXEC) : 39 quality bits (guessed)
Arg/env randomisation test (PAGEEXEC) : 39 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
Return to function (strcpy) : paxtest: return address contains a NULL byte.
Return to function (memcpy) : Return to function (strcpy, PIE) : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE) :

I can see that dmesg is restricted and sysctl -a | grep grsecurity dumping alot of variables.

Am I missing something?
eric

[PaX Team]

can you post your .config please?

[spender]

Can you also provide the contents of /proc/cpuinfo on the guest?

-Brad

[esanders83]

Here you go:

root@box01:/usr/src/linux-3.2.66# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Common KVM processor
stepping : 1
microcode : 0x1
cpu MHz : 3333.332
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall lm constant_tsc nopl pni cx16 x2apic hypervisor lahf_lm
bogomips : 6666.66
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Common KVM processor
stepping : 1
microcode : 0x1
cpu MHz : 3333.332
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall lm constant_tsc nopl pni cx16 x2apic hypervisor lahf_lm
bogomips : 6666.66
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:

[esanders83]

Here's a copy of the .config:
http://pastebin.com/8pnzeb1e

[spender]

You're probably using -cpu kvm64 which lacks NX support (for what reason, who knows, even though to our knowledge the only real 64-bit processor lacking NX was some rare Celeron D). Ideally you should use -cpu host, or failing that, a minimum of -cpu kvm64,+nx.

-Brad

[esanders83]

hello,

You're right; it was set to default(kvm64). I set it to host and it still is failing on paxtest, then i tried with (cpu: kvm64,+nx) (/etc/pve/nodes/virt01/qemu-server/100.conf) and it's still failing on paxtest.

below is the local for /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5470 @ 3.33GHz
stepping : 10
microcode : 0x1
cpu MHz : 3333.332
cache size : 6144 KB
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall lm constant_tsc arch_perfmon rep_good nopl pni ssse3 cx16 sse4_1 x2apic xsave hypervisor lahf_lm
bogomips : 6666.66
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

below is the kvm64,+nx for /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Common KVM processor
stepping : 1
microcode : 0x1
cpu MHz : 3333.332
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall lm constant_tsc nopl pni cx16 x2apic hypervisor
bogomips : 6666.66
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:

any other step to try?

thank you!

[PaX Team]

is the nx feature present in the host cpuinfo at all? also can you check dmesg (both host and guest) for "NX (Execute Disable) protection: active"?

[esanders83]

You're right; the host doesn't have NX in the cpuinfo and under the dmesg dump (it's complete); it has no NX flags anywhere.

Intel X5470 (Harpertown)?

cpuflags:
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority

I guess that's the problem; no true NX cpu flag on the host level =\

Thank you guys for your help on this; I'll use something more newer to play with!
eric

[PaX Team]

that cpu has NX support according to http://ark.intel.com/products/35430/Int ... 33-MHz-FSB, so maybe it's just disabled in the BIOS?

[esanders83]

Thank you for the note.

I just checked a quick howto from vmware where the NX is missing for the DL380 G5:
http://blog.vmpros.nl/2012/09/17/vmware ... e-enabled/

going to try in the morning.

Thank you again
eric

[spender]

What was your host kernel version?

-Brad

[kees]

What boot loader is the host using? (Legacy BIOS, UEFI, shim, grub, etc?) It's possible a boot entirely through 64-bit entry points would skip the XD-fixup code in the kernel, since it's only present on the 32-bit startup paths at the moment.

[PaX Team]

can you test this quick hack on your box (without enabling NX in the BIOS):

Code: Select all

--- a/arch/x86/kernel/head_64.S       2015-01-04 02:06:23.316996871 +0100
+++ b/arch/x86/kernel/head_64.S   2015-02-05 00:40:20.273012360 +0100
@@ -213,6 +213,13 @@
 1:

        /* Check if nx is implemented */
+       movl    $MSR_IA32_MISC_ENABLE, %ecx
+       rdmsr
+       btrl    $2, %edx                # clear MSR_IA32_MISC_ENABLE_XD_DISABLE
+       jnc     verify_cpu_check        # only write MSR if bit was changed
+       wrmsr
+
+verify_cpu_check:
        movl    $0x80000001, %eax
        cpuid
        movl    %edx,%edi

[PaX Team]

update: i tried the hack myself (needs nosmp if you still want to try it) and it works fine, so i'll leave it up to Kees to produce a proper patch for upstream .