hardened and 64bit

Hi,

I want to set up a new hardened system which will host the
usual LAMP 
(perhaps only within a VM?) and a vmware-server (since I
wasn't able to 
find a OSS (para-)virtualisation solution which would
support using 
grsecurity without hassles [*]).

Does anybody here has experiences when it comes to 64bit and
a hardened 
gentoo system (no SELinux, just grsecurity and the default
stuff  )?

I would like to stay with "stable/amd64" and not
"testing/~amd64". So can I 
assume everything works as flawlessly as with
"x86"? Or should I be careful 
and stay with 32-bit "x86"? This would be my first
amd64 system so asking 
in advance seems to be the less nerve-wracking way *g*

Thanks,
Marcel

[*]
- linux-vserver/openvz don't use several kernels and
therefore different 
  configurations for each "VM"
- XEN needs a lot of patching and is difficult to patch
together with 
  grsecurity
- KVM isn't ready yet and my CPUs don't support Pacifica
either 
- Qemu is not very powerful (performance wise)

> [*]
> - linux-vserver/openvz don't use several kernels and
therefore different
>   configurations for each "VM"
> - XEN needs a lot of patching and is difficult to patch
together with
>   grsecurity
> - KVM isn't ready yet and my CPUs don't support
Pacifica either 
> - Qemu is not very powerful (performance wise)
there is kqemu that accelerate qemu a lot(and it's now free
software/open
source)
-- 
gentoo-hardenedgentoo.org mailing list

Hi Brad,

Am Mittwoch, 18. Juli 2007 schrieb Brad Plant:
> > - XEN needs a lot of patching and is difficult to
patch together with
> >   grsecurity
>
> I have attached my ebuild and patches that I use to
create my kernels
> (hardened-xen-sources). It uses xen 3.1.0 and
grsecurity version 2.1.9,
> so make sure you install xen-tools-3.1.0 (look in
bug.gentoo.org) and
> gradm-2.1.9. Btw, PATCH_URI points to an internal
machine here just in
> case you were wondering.
>
> One more thing, this patch _only_ works with x86_64.

Thank you very much! Your contribution is much appreciated!

I will have a look at it since I'm still curious about Xen's
performance. 
But to be honest, I'm also a little bit scared due to the
non-official 
state of the patches and hence their guaranteed future. Your
statement 
about yourself running several machines successfully
reassures me .

Have a nice day,
Marcel

Am Mittwoch, 18. Juli 2007 schrieb GNUtoono-log.org:
> > - Qemu is not very powerful (performance wise)
>
> there is kqemu that accelerate qemu a lot(and it's now
free software/open
> source)
Thank you for mentioning.

But I made some performance tests with kqemu (the default:
kernel 
compile  ) and it
took significantly longer than with vmware (I don't 
remeber the exact times. But I guess it took around 40% more
time compared 
to vmware-server.).

I like qemu as a local VM for a Windows on my notebook. But
I guess it won't 
perform well enough on a server when several VMs are to be
used. I haven't 
tested on 64bit yet, however.

Marcel

On Wed, 18 Jul 2007 19:52:10 +0200
Marcel Meyer <meyermfs.tum.de> wrote:
 
> I will have a look at it since I'm still curious about
Xen's
> performance. But to be honest, I'm also a little bit
scared due to
> the non-official state of the patches and hence their
guaranteed
> future. Your statement about yourself running several
machines
> successfully reassures me .

That is certainly understandable. I have never done any
kernel programming either. My understanding is (or rathing I
am hoping) that when paravirt_ops gets merged into mainline
(looks like this happened in the last couple of days), the
PaX/grsecurity patch will apply cleanly and work together in
harmony. We will also be able to run more recent kernels
instead of only 2.6.18.

Cheers,

Brad