grsecurity forums

Purpose: to use a hardened 3.x kernel for dom0 in Xen with KERNEXEC (otherwise you would have to trust the whole kernel that there's no exploitable bugs)

In light of the fact that XEN (and/or KVM) is at the moment incompatible with KERNEXEC how secure is it to have XEN enabled and KERNEXEC disabled in dom0?
Seems with KERNEXEC enabled dom0 options that are necessary are grayed out.

Isn't this a big security risk? Seems there's no pint to linux 3.x with hardened support if you want to use Xen.

I've never actually used Xen which is what I'm interested in more than KVM. Am I wrong that you need those options? I need backend drivers for various devices which I can't select.

Do you think a fix will available soon? (Unlikely from what I've read)

According to what I found so far Xen won't work with KERNEXEC & UDEREF but KVM will.
Hope one day it will be fixed.

In searching for a solution found an interesting reply-comment by Brad on Qubes.
http://permalink.gmane.org/gmane.comp.s ... ydave/4287

My opinion, though I understand the concept of Qubes, Joanna is selling some serious snake oil with if she thinks she can ignore everything else within AppVMs. Don't understand how she can come to that conclusion if she's supposed to be such a good security researcher. (Unless I misunderstood something about her ideas).

there's a fundamental issue between the kernel self-protection mechanisms in PaX and various virtualization products. the problem is that by their nature, VMMs present a restricted model of the world to the guest kernel and some of those restrictions are exactly what the self-protection mechanisms would need (e.g., cr0.wp or ring-0 segment limits). so the short answer is that such conflicts won't be fixed anytime soon and even if they were, the fixes/changes would have to apply to both PaX and the Xen/KVM hypervisor side as well.