# Notice: NX protection cannot be enabled: non-PAE kernel!

## josephg

i see this in dmesg. should i consider having those enabled?

```
Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!
```

i think pae got disabled, as I don't have more than 4g ram. i do have the nx and pae flags in my cpu. my kernel is gentoo 32bit x86.

----------

## s4e8

You must select HIGHMEM 64G or HIGHMEM off + PAE on. With PAE on you got max 64G highmem, and 4G PAE off, it's pointless with PAE on and limit HIGHMEM to 4G.

----------

## Ant P.

If you're still using a 32-bit CPU, the added overhead of PAE probably isn't worth it. NX is mostly useful on precompiled distros.

----------

## josephg

 *Ant P. wrote:*   

> If you're still using a 32-bit CPU, the added overhead of PAE probably isn't worth it. NX is mostly useful on precompiled distros.

 

my cpu is 64bit, but i still prefer 32bit os as i find it more resource efficient and stable.

i was wondering about the pae overhead, and usefulness of nx. this was what i was debating.. about switching those overheads on vs the potential benefits. thanks for that.. if they are only useful on precompiled distros.. then i'm not too worried.

btw, why would nx protection be useful on precompiled distros, and not on the likes of gentoo?

----------

## NeddySeagoon

josephg,

You can run a 64 bit kernel under your 32 bit userspace if you really want to.  

That avoids all the HIMEM work arounds in 32 bit if you have more than 1G RAM.

You just can't easily build a 64 bit kernel on a 32 bit install.

With 2G or more of RAM, you should go 64 bit anyway. 

NX is useful against buggy software and things you didn't even know you had installed.

It stops code being run in areas of memory that should no be executable, like dynamically allocated RAM. A Programs data region and so on.

This causes a few badly designed programs to get killed.  It also stops some classes of exploits.

----------

## Hu

NX is useful everywhere, regardless of whether the distribution is precompiled.  ASLR is also useful everywhere, but is more important on precompiled distributions, since an attacker can predict the exact contents of your programs because he can download the same copy you downloaded.  If you have no ASLR and the attacker can predict memory layout, various attacks become much easier.  Since Gentoo users tend to build everything locally, the attacker knows generally what your program will do, but may not be able to predict the exact layout of the program.  This slightly reduces the need to have ASLR.  However, in 64-bit mode, ASLR is free, so there is no reason not to have it.  In 32-bit mode, ASLR requires building everything as PIC, which consumes one register on an architecture that is already register starved.  You should only run 32-bit if your CPU is incapable of 64-bit mode.

----------

## josephg

 *Hu wrote:*   

> In 32-bit mode, ASLR requires building everything as PIC, which consumes one register on an architecture that is already register starved.  You should only run 32-bit if your CPU is incapable of 64-bit mode.

 

guess, aslr is overkill for me.

i don't need the 64b overheads on memory or diskspace. i don't have more than 4g ram to justify moving to 64bit. and i don't think i can have a pure 64b os either. so even though my cpu is 64b, keeping myself pure 32b is more efficient.

 *NeddySeagoon wrote:*   

> You can run a 64 bit kernel under your 32 bit userspace if you really want to. 
> 
> That avoids all the HIMEM work arounds in 32 bit if you have more than 1G RAM.

 

i was thinking that keeping my system pure 32bit would be the most efficient. is 32bit userpace running on a 64bit kernel more efficient if more than 1g ram?

----------

