grsecurity forums

Hi,

I'm trying to start a fedora paravirtualized Xen guest with
a 3.15.3-grsec kernel, but the guest fails to start (host system is Qubes OS).

hypervisor.log from the time when I try to startup the grsec guest:
http://pastebin.com/cNQTnnUR


kernel config:
http://pastebin.com/yQZrY6bL

Is grsecurity's Xen guest support limited to a certain guest type (PV vs. HVM) or is there no such limitation?

Documentation doesn't specifically mention this point.

https://en.wikibooks.org/wiki/Grsecurit ... ptions#Xen


If PV Xen guests are supported:
How could I further debug this problem?

thank you for your help!

can you try to nail it down to any particular PaX feature that triggers this?

I recompiled to be able to boot with pax_softmode=1, but booting fails also in softmode. (or did I misunderstood the softmode feature?)

So the process to nail that down without softmode would be to compile the kernel with many different configs and see when it stops failing, correct?

thanks!

joe wrote:I recompiled to be able to boot with pax_softmode=1, but booting fails also in softmode. (or did I misunderstood the softmode feature?)

softmode only affects the userland features (non-exec pages and ASLR), your problem occurs way before userland starts up .

So the process to nail that down without softmode would be to compile the kernel with many different configs and see when it stops failing, correct?

yes, you can do a binary search on the config options, best is to start with all grsec/PaX features disabled so that we know whether the baseline works or not (there're features which are not under .config control).

PS: i forgot to ask last time, can you resolve ffffffff81189fac to a symbol in the guest kernel's vmlinux binary?

PAX detected a size overflow:

Code: Select all

PAX: size overflow detected in function HYPERVISOR_event_channel_op /home/user/rpmbuild/BUILD/kernel-3.15.3/linux-3.15.3/arch/x86/include/asm/xen/hypercall.h:367 cicus.411_18 max, count: 1


full trace:
http://pastebin.com/2SJ0tqPJ

How "exploitable" is that bug?


With that information it was easy to find the relevant option, disabling

Code: Select all

CONFIG_PAX_SIZE_OVERFLOW


produces a booting kernel.

thanks for the report, Emese will look into it and let us know if it's a real bug. from a quick glance this looks like an integer truncation problem (unsigned long -> int) on a return value and i don't think this is a security issue, but more like somewhat sloppy programming.

Thanks for the report. It is a false positive. This bug will be fixed in the next PaX version.

As it is still a work in progress just a short update:

- I switched from 3.15.x. to 3.14.x for its longer support.
using grsecurity-3.0-3.14.12-201407170638.patch

- 3.14.x seems to have more/other issues(?)

not working kernel config:
http://pastebin.com/Vx9LYdv3

bootup output:
http://pastebin.com/HPdRF2td

Note: CONFIG_PAX_SIZE_OVERFLOW is not set

by disabling all features under 'Miscellaneous hardening features' I'm able to get a working kernel.

Code: Select all

6569,6571c6569,6571
< CONFIG_PAX_MEMORY_SANITIZE=y
< CONFIG_PAX_MEMORY_STACKLEAK=y
< CONFIG_PAX_MEMORY_STRUCTLEAK=y
---
> # CONFIG_PAX_MEMORY_SANITIZE is not set
> # CONFIG_PAX_MEMORY_STACKLEAK is not set
> # CONFIG_PAX_MEMORY_STRUCTLEAK is not set
6573,6574c6573
< CONFIG_PAX_USERCOPY=y
< # CONFIG_PAX_USERCOPY_DEBUG is not set
---
> # CONFIG_PAX_USERCOPY is not set
6576c6575
< CONFIG_PAX_LATENT_ENTROPY=y
---
> # CONFIG_PAX_LATENT_ENTROPY is not set


I'm now in the process to narrow down the option causing the problem.

Let me know if I should open a new thread.

The relevant option that causes the problem as soon as it is enabled:

Code: Select all

CONFIG_PAX_MEMORY_STACKLEAK


I guess you need more from me then just the config option to have a look at this?

can you resolve the reported RIP value (ffffffff811873cc) in vmlinux to a symbol (e.g., with addr2line)?

Sorry for the delay I didn't see your reply sooner.

Code: Select all

addr2line -e vmlinux -f ffffffff8118db1c
pax_track_stack
??:?


(the RIP value changed with my latest build using 3.14.15)

what happens here is that the STACKLEAK instrumentation call gets called too early to be able to access percpu data and that ends up in a NULL deref. what i'll do in the next patch is that i'll disable the instrumentation on all init code where it makes little sense anyway and hopefully that'll make it go further under Xen as well.

Thanks for the fix!
I can confirm that grsecurity-3.0-3.14.15-201408032014 works with
CONFIG_PAX_MEMORY_STACKLEAK enabled on Xen guests now.