grsecurity forums

Hello,
I want to setup a box, running on 2.6 (2.6.14.7 for example) that will use up to 3-4 GB of virtual memory (2 GB RAM + 1-2 GB swap).

It will be running on amd64 dual core, in SMP mode. Im not shure will the kernel work in 64 or 32 bit mode.

If I choose 32 bit (SMP), what is the limit of phisical and virtual memory my kernel can use (and how much single process can use at once)?

Same question for 64 bit mode kernel (and how much 32 bit mode application running in 32 bit chroot would be able to allocate for itself).

How stable is 32-smp and 64-smp, for 2.6.14.7?
How secure is 64bit kernel (more randomization perhaps?)
Any important things to watch out for?

ps. it will be mainly a desktop, using Xorg+nvidia

Thanks in advice

I am running grsecurity with alot of memory with no problems.
Anyway I don't underestand what for is grsecurity on a workstation. ;)

Regards.

Platyna wrote:I am running grsecurity with alot of memory with no problems.
Anyway I don't underestand what for is grsecurity on a workstation.
Regards.

A lot means how much exacly? RAM/swap? 64bit cpu, in 64bit kernel mode?

Well, on desktop workstation grsecurity is usable as well, I dont want in example exploit in IRC client to allow to steal some documents from my users account, or install zombie that would send out SPAM from my machine.

Since grsecurity do not slow down machine noticibly (for common cases), why not use it

Raf256 wrote:If I choose 32 bit (SMP), what is the limit of phisical and virtual memory my kernel can use (and how much single process can use at once)?

there's no particular limit imposed by grsec on these, the only thing that can affect you is userland address space size if you use SEGMEXEC (it's halved), but then why would you run a 32 bit kernel on a 64 bit CPU?

Same question for 64 bit mode kernel (and how much 32 bit mode application running in 32 bit chroot would be able to allocate for itself).

same as above except there's no SEGMEXEC imposed limit as there's no SEGMEXEC under a 64 bit kernel, you'd be using the hardware NX bit (even for 32 bit userland). the userland address space size is almost 4GB under a 64 bit kernel, so with some attention to how you link your apps (statically with a lower than normal base address), you can allocate all of it as one chunk (well, modulo randomization).

How stable is 32-smp and 64-smp, for 2.6.14.7?

as far as i'm concerned, PaX for 2.6 is highly experimental so 'anything can break at any time', in practice it tends to survive quite well though.

How secure is 64bit kernel (more randomization perhaps?)

randomization is userland security, not kernel, but other than that, yes, on a 64 bit kernel PaX provides a lot more randomization:

Anonymous mapping randomisation test : 33 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 40 bits (guessed)
Main executable randomisation (ET_EXEC) : 33 bits (guessed)
Main executable randomisation (ET_DYN) : 33 bits (guessed)
Shared library randomisation test : 33 bits (guessed)
Stack randomisation test (SEGMEXEC) : No randomisation
Stack randomisation test (PAGEEXEC) : 40 bits (guessed)

the 2.6 kernel itself is the least secure linux series if you've got untrusted local users, and it's unlikely to change anytime soon. on a personal desktop it's probably not such a big issue if you pay some attention to what untrusted code you run.