grsecurity forums

Hello,

Since yesterday I am facing the same problem as mentioned here: https://forums.grsecurity.net/viewtopic ... ack2#p9157. I run an x86 heardened gentoo as guest on kvm. The host system is an amd64 hardened gentoo(with nx bit). Until I removed pageexec (as paxteam suggested at the last reply of the aforementioned topic) every time I ran paxtest it would not finish, having getstack2 using 100% of the cpu. While using both segmexec and pageexec I tried running the guest with and without nx bit enabled (-cpu host and -cpu pentium3 respectively), but without any success running gettack2 correctly.
So now, in order to have it working I have my guest without nxbit, and with pageexec disabled.

In all my other x86 pcs (physical not virtual pcs) I am able having both segmexec and pageexec enabled(only one of these has nx bit).

Although I am using segmexec as a noexec method aren't there any other benefits for using pageexec also?
Can they be both used simultaneously(the way that they are configured on my other x86 pcs)?
If not, how can I say which is used? Which one should I prefer?
If they can is there a any suggestion for fixing it for my kvm guest?

Thank you for your time

yiannis.k wrote:Since yesterday I am facing the same problem as mentioned here: https://forums.grsecurity.net/viewtopic ... ack2#p9157. I run an x86 heardened gentoo as guest on kvm. The host system is an amd64 hardened gentoo(with nx bit). Until I removed pageexec (as paxteam suggested at the last reply of the aforementioned topic) every time I ran paxtest it would not finish, having getstack2 using 100% of the cpu. While using both segmexec and pageexec I tried running the guest with and without nx bit enabled (-cpu host and -cpu pentium3 respectively), but without any success running gettack2 correctly.

does kvm provide the nx bit to the guest kernel (check /proc/cpuinfo in the guest)? does your guest kernel make use of the nx bit (check the guest config for PAE)?

PaX Team wrote:does kvm provide the nx bit to the guest kernel (check /proc/cpuinfo in the guest)? does your guest kernel make use of the nx bit (check the guest config for PAE)?

Yes it does provide the nx to the guest. Also with PAE enabled everything works as it should. But I am planning to use this vm as a host for providing ebuilds(and compiled kernels) for the rest of my pcs which does not have an nx bit. Although on these pcs I am able to use a kernel with both pageexec & segmexec. Shouldn't it be also possible with a 32bit vm without nx bit? (This is where the rest of the questions from my first post stem from).

yiannis.k wrote:But I am planning to use this vm as a host for providing ebuilds(and compiled kernels) for the rest of my pcs which does not have an nx bit.

i don't understand this part . what do the emerged kernels have to do with the kernel running in the VM? i.e., why can't you have the VM guest kernel with PAE (and PAGEEXEC using the nx bit) but compile a non-PAE kernel for your other machines? or do you want these to be the same? also why can't you have a PAE kernel everywhere?

Although on these pcs I am able to use a kernel with both pageexec & segmexec. Shouldn't it be also possible with a 32bit vm without nx bit? (This is where the rest of the questions from my first post stem from).

if you don't enable PAE and/or don't have an nx-capable CPU then the old PAGEEXEC method will be used which is not compatible with virtualization (it plays with the TLB). the reason you see only getstack2 fail (get stuck) is because it's explicitly set up to use PAGEEXEC over SEGMEXEC (that's the point of that test). so in your setup it will never work.

PaX Team wrote:i don't understand this part . what do the emerged kernels have to do with the kernel running in the VM? i.e., why can't you have the VM guest kernel with PAE (and PAGEEXEC using the nx bit) but compile a non-PAE kernel for your other machines? or do you want these to be the same? also why can't you have a PAE kernel everywhere?

This is exactly what I want to accomplish. Having the same kernel on all my x86 pcs. I mean on most of them. To be more specific, I have 3 (really)old x86 pcs without nx bit and one 32bit via(c7-d cpu) with nx bit. Also I have an intel core 2 duo (which is my kvm host). On the kvm host I was trying to run a guest without nx bit and without pae just to be able to distribute the same kernel to the rest of my pcs (except the via).
Until now I am able to run the same kernel on my 3 physical pcs(these without nx) having pageexec and segmexec enabled. So I thought it would be possible to do the same on the kvm guest, and distribute its kernel to the rest - slower - pcs. By reading the rest of your reply I conclude that my best shot is having pageexec & segmexec & pae enabled on a nx enabled guest(As I have it on the via).

if you don't enable PAE and/or don't have an nx-capable CPU then the old PAGEEXEC method will be used which is not compatible with virtualization (it plays with the TLB). the reason you see only getstack2 fail (get stuck) is because it's explicitly set up to use PAGEEXEC over SEGMEXEC (that's the point of that test). so in your setup it will never work.

This is where I got caught. I thought that having pageexec(and segmexec) enabled on my x86 pcs would act the same for my kvm guest.


Thank you very much for your time and help. Sorry for the bad English torturing (usual apology, but very true )

You and grsec help me go to bed with less worries.

yiannis.k wrote:This is exactly what I want to accomplish. Having the same kernel on all my x86 pcs. I mean on most of them. To be more specific, I have 3 (really)old x86 pcs without nx bit and one 32bit via(c7-d cpu) with nx bit. Also I have an intel core 2 duo (which is my kvm host). On the kvm host I was trying to run a guest without nx bit and without pae just to be able to distribute the same kernel to the rest of my pcs (except the via).

i don't quite understand your problem with kvm then. the order in which PaX tries to do non-exec pages on in 386 is this:

1. PAGEEXEC with the NX bit (when the cpu has it and the kernel has PAE enabled)
2. SEGMEXEC
3. PAGEEXEC with TLB manipulation (when there's no NX bit and/or PAE, and there's no SEGMEXEC or PAGEEXEC is explicitly requested over SEGMEXEC on a binary, such as getstack2)

so as you can see, the 'worst' that could happen with a PAGEEXEC/SEGMEXEC/PAE kernel is that it'd fall back to SEGMEXEC (that must work everywhere, including virtual machines). so except for getstack2, what other problems are you having exactly?

This is where I got caught. I thought that having pageexec(and segmexec) enabled on my x86 pcs would act the same for my kvm guest.

but it does act the same, the non-exec implementation order doesn't change just because you're in a virtual machine. what does change is that the oldest non-exec method isn't compatible with virtual macines (or at least not most of them, maybe it works with EPT and stuff, i never tried, but then you have NX on such CPUs, so it'd be an academic exercise only).

in short, if your only problem is with getstack2, then simply don't run it .

Hello,

Sorry for the delayed reply:

PaX Team wrote:i don't quite understand your problem with kvm then. the order in which PaX tries to do non-exec pages on in 386 is this:

1. PAGEEXEC with the NX bit (when the cpu has it and the kernel has PAE enabled)
2. SEGMEXEC
3. PAGEEXEC with TLB manipulation (when there's no NX bit and/or PAE, and there's no SEGMEXEC or PAGEEXEC is explicitly requested over SEGMEXEC on a binary, such as getstack2)

so as you can see, the 'worst' that could happen with a PAGEEXEC/SEGMEXEC/PAE kernel is that it'd fall back to SEGMEXEC (that must work everywhere, including virtual machines). so except for getstack2, what other problems are you having exactly?

Besides getstack2, I have no other problems. Mostly I panicked about coming across with a similar situation at some other "more important" program.

but it does act the same, the non-exec implementation order doesn't change just because you're in a virtual machine. what does change is that the oldest non-exec method isn't compatible with virtual macines (or at least not most of them, maybe it works with EPT and stuff, i never tried, but then you have NX on such CPUs, so it'd be an academic exercise only).

in short, if your only problem is with getstack2, then simply don't run it .

Yes indeed. I won't.
Thank you for clarifying all these topics.