On 03/01/2011 03:08 PM, pageexec@freemail.hu wrote:
> On 1 Mar 2011 at 16:52, Marcel Meyer wrote:
>
>> On Sunday 27 February 2011 17:20:25 Pavel Labushev wrote:
>>> 27.02.2011 22:32, "Tóth Attila" :
>>> http://grsecurity.net/pipermail/grsecurity/2010-April/001024.html - from
>> here:
>>
>> So if I understand pageexec's mail correctly, using a 32-bit hardened domU-
>> kernel is more performant than the 64-variant when using UDEREF?
>
> i believe xen doesn't/cannot support UDEREF in paravirt mode,

Confirmed.

> in HVM mode
> i386 should be fine, amd64 should be dead slow.

In my experience, both are fine. I run hardened x86, hardened amd64 and
hardened amd64 nomultilib as domU. The host is OpenSuse 11.3. I have
both KERNEXEC and UDEREF on, no noticeable problems.

KVM is a different story, and I do see slowdown for amd64.

--
Anthony G. Basile, Ph.D.
Gentoo Developer

On 1 Mar 2011 at 18:28, Anthony G. Basile wrote:

> > in HVM mode
> > i386 should be fine, amd64 should be dead slow.
>
> In my experience, both are fine. I run hardened x86, hardened amd64 and
> hardened amd64 nomultilib as domU. The host is OpenSuse 11.3. I have
> both KERNEXEC and UDEREF on, no noticeable problems.

now that's interesting, does the host have/use EPT (or amd's equivalent)?

> KVM is a different story, and I do see slowdown for amd64.

this means that the slowdown is truly specific to some kvm/uderef interaction,
not that i have an idea where to look still...

On 3/1/2011 6:22 PM, Anthony G. Basile wrote:
> On 03/01/2011 03:02 PM, pageexec@freemail.hu wrote:
>> On 28 Feb 2011 at 15:39, Daniel Reidy wrote:
>>
>>> On Sun, Feb 27, 2011 at 5:58 PM, <pageexec@freemail.hu> wrote:
>>>> that's actually not the intended use of the PIC USE flag, we wanted it originally
>>>> to enable configuring/compiling position independent code for packages where one
>>>> wanted to make a tradeoff between speed/security (i think php was one such app,
>>>> even without any hand written asm code).
>>>>
>>>> so with USE=pic you were supposed to get a textrel free, but potentially slower
>>>> binary (partly because of the PIC overhead on i386 and partly because sometimes
>>>> it meant using the C implementation of some algo instead of hand written asm).
>>>
>>> So if I understand this correctly, we should now be turning off PIC on
>>> Gentoo-Hardened systems running on AMD64. What about the non-hardened
>>> variety, such as my desktop, that is only running a "stock" version of
>>> Gentoo Sources without hardened features?
>>
>> USE=pic should have exactly 0 effect on amd64 because the arch and the ELF ABI
>> makes PIC zero cost basically. if some package manages to get around the rules
>> somehow, it's a bug in that package, treat it accordingly .
>>
>
> This was Zorry's point. So if it has no effect, why keep it? I say
> let's remove it.

There is no point in keeping it. This discussion has mostly been about
reassuring people with less intimate knowledge of the AMD64 ABI of that
fact

On 2 Mar 2011 at 22:10, Peter Hjalmarsson wrote:

> > > KVM is a different story, and I do see slowdown for amd64.
> >
> > this means that the slowdown is truly specific to some kvm/uderef interaction,
> > not that i have an idea where to look still...
>
> Are you missing anything you need to figure this out, like profiling
> data?

well, i've tried profiling with another user already but there was no
conclusive data as to what could be the cause of the slowdown. it seems
to be related to the generation of lots of extra page faults, something
i'd even understand for UDEREF, but it also happens with KERNEXEC which
is a mystery. also it seems to depend on the number of host CPUs, i could
never really reproduce the slowdown on 2 cores, but it always occurs on
3+ host cores. i guess at this point someone familiar with KVM internals
would have to be asked about this issue...

ons 2011-03-02 klockan 10:28 +0200 skrev
pageexec@freemail.hu:
> On 1 Mar 2011 at 18:28, Anthony G. Basile wrote:
>
> > > in HVM mode
> > > i386 should be fine, amd64 should be dead slow.
> >
> > In my experience, both are fine. I run hardened x86, hardened amd64 and
> > hardened amd64 nomultilib as domU. The host is OpenSuse 11.3. I have
> > both KERNEXEC and UDEREF on, no noticeable problems.
>
> now that's interesting, does the host have/use EPT (or amd's equivalent)?
>
> > KVM is a different story, and I do see slowdown for amd64.
>
> this means that the slowdown is truly specific to some kvm/uderef interaction,
> not that i have an idea where to look still...
>
>
>

Are you missing anything you need to figure this out, like profiling
data?

On 03/02/2011 03:28 AM, pageexec@freemail.hu wrote:
> On 1 Mar 2011 at 18:28, Anthony G. Basile wrote:
>
>>> in HVM mode
>>> i386 should be fine, amd64 should be dead slow.
>>
>> In my experience, both are fine. I run hardened x86, hardened amd64 and
>> hardened amd64 nomultilib as domU. The host is OpenSuse 11.3. I have
>> both KERNEXEC and UDEREF on, no noticeable problems.
>
> now that's interesting, does the host have/use EPT (or amd's equivalent)?
>
>> KVM is a different story, and I do see slowdown for amd64.
>
> this means that the slowdown is truly specific to some kvm/uderef interaction,
> not that i have an idea where to look still...
>


The guests are stock hardened gentoo (x86, amd64, amd64 nomulti) with
all hardening features enabled. On the OpenSuse 11.3 hosts, I have:


xen5:~ # cat /proc/cpuinfo

... (8 identical cores)

processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
stepping : 5
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 7
siblings : 1
core id : 0
cpu cores : 1
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush
acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good
nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt
hypervisor lahf_lm ida
bogomips : 5348.42
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:


xen5:~ # uname -a
Linux xen5 2.6.34.7-0.7-xen #1 SMP 2010-12-13 11:13:53 +0100 x86_64
x86_64 x86_64 GNU/Linux


xen5:~ # rpm -qa | grep xen
xen-tools-4.0.1_21326_02-0.5.1.x86_64
xen-libs-4.0.1_21326_02-0.5.1.x86_64
xen-4.0.1_21326_02-0.5.1.x86_64
kernel-xen-2.6.34.7-0.7.1.x86_64





--
Anthony G. Basile, Ph.D.
Gentoo Developer