grsecurity forums

Title:
Memory Protection Affecting Boot on Xen Host

Hey guys,

I'm thinking that certain Grsecurity and/or PaX kernel config options related to memory protection are affecting the boot process on Xen hosts. Below I've linked to two "Security options" config menus. The first one results in a malfunctioning boot process, but the second one works ok. This is for latest Gentoo hardened-sources on Linode, running today.

Original (malfunctions): http://pastebin.com/TBNTNiWp
New (works ok): http://pastebin.com/rh1j9xzW

I've scanned through both myself, and posted the differences below.

Grsecurity Options - diffd

Code: Select all

From:   Security Level (Hardened Gentoo [server])
To:      Security Level (Custom)

From:   -*- Disable privileged I/O
To:      [ ] Disable privileged I/O

From:   -*- Hide kernel symbols
To:      [ ] Hide kernel symbols

From:   [*] Log execs within chroot
To:      [ ] Log execs within chroot

From:   [*] Ptrace logging
To:      [ ] Ptrace logging

From:   [*] Chdir logging
To:      [ ] Chdir logging

From:   -*- (Un)Mount logging
To:      [ ] (Un)Mount logging

From:   -*- Time change logging
To:      [ ] Time change logging

From:   -*- Sysctl support &&   -*- Turn on features by default
To:      [ ] Sysctl support

From:   (6) Number of messages in a burst (maximum)
To:      (4) Number of messages in a burst (maximum)

PaX Options - diffd

Code: Select all

From:   MAC system integration (none)
To:      MAC system integration (direct)

From:   [*] Emulate trampolines
To:      [ ] Emulate trampolines

From:   [*] Sanitize kernel stack
To:      [ ] Sanitize kernel stack

From:   -*- Prevent various kernel object reference counter overflows
To:      [ ] Prevent various kernel object reference counter overflows

When I booted with the first config, this is what happened:


Could anyone guess which config option(s) would lead to this behavior?

sysx wrote:

Code: Select all

From:   [*] Sanitize kernel stack
To:      [ ] Sanitize kernel stack


my bet would be on this one, but you should really get the xen logs to see what happened to the guest kernel.

PS. is that url a live session of yours? might not be the best idea to post it to the public...

fwiw, this is still a problem with 2.6.32.59 and the current (as of today) patch, and you're right that it's the sanitize kernel stack option... or at least I can boot with it disabled.


With "Sanitize kernel stack" enabled, I see two xen-related printks and then the kernel dies. I don't control the host, so unfortunately I can't do much debugging beyond that.