[gentoo-hardened] Remove the pic use flag in the hardened amd64 profile.

[gentoo-hardened] Remove the pic use flag in the hardened amd64 profile.

[Magnus Granberg]

Hi

If you have read the last meeting we will be removing the pic use flag as 
default on in the hardened amd64 profile. We will start with the changes when 
the new structure to the profiles have settled down.
The tracker bug for this is http://bugs.gentoo.org/show_bug.cgi?id=348050
We will start with some packages like php, mesa and gzip and move on.
If some one want to test you can test that with to put -pic in USE in the 
make.conf file and recompile the packages that haved pic use flag on.

PS This changes it only fo the hardened amd64 profile.
/Magnus (Zorry)

Re: [gentoo-hardened] Remove the pic use flag in the hardened amd64 profile.

[Ed W]

On 26/02/2011 18:01, Magnus Granberg wrote:
> If you have read the last meeting we will be removing the pic use flag as
> default on in the hardened amd64 profile. We will start with the changes when
> the new structure to the profiles have settled down.

Hi, any chance of a bit of background on this change?  ie the "why" and 
some of the implications?

Apologies if this is a very ignorant question?

Thanks

Ed W

Re: [gentoo-hardened] Remove the pic use flag in the hardened amd64 profile.

[klondike]

2011/2/27 Ed W <lists@wildgooses.com>:
> On 26/02/2011 18:01, Magnus Granberg wrote:
>>
>> If you have read the last meeting we will be removing the pic use flag as
>> default on in the hardened amd64 profile. We will start with the changes
>> when
>> the new structure to the profiles have settled down.
>
> Hi, any chance of a bit of background on this change?  ie the "why" and some
> of the implications?
Summing it up a lot, amd64 usually needs not special  asm code for PIC
due to the way the ABI is defined (which means being PIC by default
usually).

That's not always the case, i.e. aircrack needed special PIC code, but
in general it shouldn't be a problem.

[gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Sun, 27 Feb 2011 09:20:57 +0100
klondike <franxisco1988@gmail.com> wrote:

> 2011/2/27 Ed W <lists@wildgooses.com>:
> > On 26/02/2011 18:01, Magnus Granberg wrote:
> >>
> >> If you have read the last meeting we will be removing the pic use flag as
> >> default on in the hardened amd64 profile. We will start with the changes
> >> when
> >> the new structure to the profiles have settled down.
> >
> > Hi, any chance of a bit of background on this change?  ie the "why" and some
> > of the implications?
> Summing it up a lot, amd64 usually needs not special  asm code for PIC
> due to the way the ABI is defined (which means being PIC by default
> usually).

You summed it up too much.  Why does this need to change?


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Magnus Granberg]

On Sunday 27 February 2011 10.11.58 Ryan Hill wrote:
> On Sun, 27 Feb 2011 09:20:57 +0100
> 
> klondike <franxisco1988@gmail.com> wrote:
> > 2011/2/27 Ed W <lists@wildgooses.com>:
> > > On 26/02/2011 18:01, Magnus Granberg wrote:
> > >> If you have read the last meeting we will be removing the pic use flag
> > >> as default on in the hardened amd64 profile. We will start with the
> > >> changes when
> > >> the new structure to the profiles have settled down.
> > > 
> > > Hi, any chance of a bit of background on this change?  ie the "why" and
> > > some of the implications?

Most of the asm code is in libs and on amd64 it need to be PIC friendly from 
the start. We don't need to disable asm code. We do that most times with the 
pic use flag on hardened profile.

/Magnus
> > 
> > Summing it up a lot, amd64 usually needs not special  asm code for PIC
> > due to the way the ABI is defined (which means being PIC by default
> > usually).
> 
> You summed it up too much.  Why does this need to change?

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

["Tóth Attila"]

2011.Február 27.(V) 13:54 időpontban Magnus Granberg ezt írta:
> On Sunday 27 February 2011 10.11.58 Ryan Hill wrote:
>> On Sun, 27 Feb 2011 09:20:57 +0100
>>
>> klondike <franxisco1988@gmail.com> wrote:
>> > 2011/2/27 Ed W <lists@wildgooses.com>:
>> > > On 26/02/2011 18:01, Magnus Granberg wrote:
>> > >> If you have read the last meeting we will be removing the pic use
>> flag
>> > >> as default on in the hardened amd64 profile. We will start with the
>> > >> changes when
>> > >> the new structure to the profiles have settled down.
>> > >
>> > > Hi, any chance of a bit of background on this change?  ie the "why"
>> and
>> > > some of the implications?
>
> Most of the asm code is in libs and on amd64 it need to be PIC friendly
> from
> the start. We don't need to disable asm code. We do that most times with
> the
> pic use flag on hardened profile.
>
> /Magnus

I'm still running Hardened on x86. I'm thinking of the optimal time to
switch to amd64. Is it better from the security point of view?
I assume, that it's easier to make amd64 asm code PIC-aware because of the
higher number of available registers.

Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

>> >
>> > Summing it up a lot, amd64 usually needs not special  asm code for PIC
>> > due to the way the ABI is defined (which means being PIC by default
>> > usually).
>>
>> You summed it up too much.  Why does this need to change?
>

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Anthony G. Basile]

On 02/27/2011 08:03 AM, "Tóth Attila" wrote:
> 2011.Február 27.(V) 13:54 időpontban Magnus Granberg ezt írta:
>> On Sunday 27 February 2011 10.11.58 Ryan Hill wrote:
>>> On Sun, 27 Feb 2011 09:20:57 +0100
>>>
>>> klondike <franxisco1988@gmail.com> wrote:
>>>> 2011/2/27 Ed W <lists@wildgooses.com>:
>>>>> On 26/02/2011 18:01, Magnus Granberg wrote:
>>>>>> If you have read the last meeting we will be removing the pic use
>>> flag
>>>>>> as default on in the hardened amd64 profile. We will start with the
>>>>>> changes when
>>>>>> the new structure to the profiles have settled down.
>>>>>
>>>>> Hi, any chance of a bit of background on this change?  ie the "why"
>>> and
>>>>> some of the implications?
>>
>> Most of the asm code is in libs and on amd64 it need to be PIC friendly
>> from
>> the start. We don't need to disable asm code. We do that most times with
>> the
>> pic use flag on hardened profile.
>>
>> /Magnus
> 
> I'm still running Hardened on x86. I'm thinking of the optimal time to
> switch to amd64. Is it better from the security point of view?
> I assume, that it's easier to make amd64 asm code PIC-aware because of the
> higher number of available registers.
> 
> Dw.

This is a loaded question.  For many exploits it does not make a
difference if you are on 64 or 32 bits.  For some it does.

An example of where it doesn't make a difference is a classic buffer
overflow.

An example of where it does is an attempt to defeat address space
randomization by brute force.  32-bit address space is only 4G which is
not impossibly large for success by brute force while 64-bits is about
10^19.  A lot harder.

And then, to complicate matters, 64-bit with 32-bit compat opens up yet
another family of exploits, like the one Dan Rosenberg found a few
months back which abused the way 32-bit syscalls were treated by 64-bit
kernels with 32-bit compat.


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

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Pavel Labushev]

27.02.2011 21:53, Anthony G. Basile пишет:

> An example of where it does is an attempt to defeat address space
> randomization by brute force.  32-bit address space is only 4G which is
> not impossibly large for success by brute force while 64-bits is about
> 10^19.  A lot harder.

Another point: UDEREF on x86 is more reliable than on amd64. Choose x86 if
your big concern is to protect the kernel from userland (like, if you use
privilege separation/revocation not just because it looks fancy on paper).

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

["Tóth Attila"]

2011.Február 27.(V) 16:19 időpontban Pavel Labushev ezt írta:
> 27.02.2011 21:53, Anthony G. Basile пишет:
>
>> An example of where it does is an attempt to defeat address space
>> randomization by brute force.  32-bit address space is only 4G which is
>> not impossibly large for success by brute force while 64-bits is about
>> 10^19.  A lot harder.
>
> Another point: UDEREF on x86 is more reliable than on amd64. Choose x86 if
> your big concern is to protect the kernel from userland (like, if you use
> privilege separation/revocation not just because it looks fancy on paper).
>

More reliable? Interesting. Do you have a link about this?
Apart from older systems 32bit will be with us at least because of the ARM
architecture.

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Pavel Labushev]

27.02.2011 22:32, "Tóth Attila" пишет:

> More reliable? Interesting. Do you have a link about this?
> Apart from older systems 32bit will be with us at least because of the ARM
> architecture.

http://grsecurity.net/pipermail/grsecurity/2010-April/001024.html - from here:

> this is also where the similarities end :), so let's look at the bad stuff
> now. UDEREF/amd64 doesn't ensure that the (legitimate) userland accessor
> functions cannot actually access kernel memory when only userland is allowed
> (some in-kernel users of certain syscalls can temporarily access kernel memory
> as userland, and that is enforced on UDEREF/i386 but not on amd64). so if
> there's a bug where userland can trick the kernel into accessing a userland
> pointer that actually points to kernel space, it'll succeed, unlike on i386.
> 
> the other bad thing is the presence of the userland shadow area. this has
> two consequences: 1. the userland address space size is smaller under UDEREF
> (42 vs. 47 bits, with corresponding reduction of ASLR of course), 2. this
> shadow area is always mapped so kernel code accidentally accessing its range
> may not oops on it and can be exploited (such accesses can usually happen only
> if an exploit can make the kernel dereference arbitrary addresses in which
> case the presence of this area is the least of your concerns though).
> 
> what about performance? well, 'it depends', in particular it depends on the
> amount of user/kernel transitions of your workload as that's where the extra
> code really hits (it's basically a TLB flush and two CR0 writes if you have
> KERNEXEC as well, say 600 cycles + TLB repopulation time). on a simple
> compilation test i get these times:

Re: [gentoo-hardened] Remove the pic use flag in the hardened amd64 profile.

[Ed W]

On 27/02/2011 08:20, klondike wrote:
> 2011/2/27 Ed W<lists@wildgooses.com>:
>> On 26/02/2011 18:01, Magnus Granberg wrote:
>>> If you have read the last meeting we will be removing the pic use flag as
>>> default on in the hardened amd64 profile. We will start with the changes
>>> when
>>> the new structure to the profiles have settled down.
>> Hi, any chance of a bit of background on this change?  ie the "why" and some
>> of the implications?
> Summing it up a lot, amd64 usually needs not special  asm code for PIC
> due to the way the ABI is defined (which means being PIC by default
> usually).
>
> That's not always the case, i.e. aircrack needed special PIC code, but
> in general it shouldn't be a problem.
>

Sorry to probe further, but I'm not getting the big picture (durr)

I think what you are saying is that using PIC requires some special 
handling (but that work seems largely done now?).  However, does 
removing PIC leave the AMD64 architecture "less secure" in some way? Or 
is some other procedure now replacing PIC?

My minimal understanding is that PIC is a key part of the address space 
randomisation that is considered useful for system hardening. Where does 
removing PIC leave us in that process?

So, sorry to be the dimwit, but can you give me a beginners guide to the 
implications of this change?

Ta

Ed W

Re: [gentoo-hardened] Remove the pic use flag in the hardened amd64 profile.

[Mike Edenfield]

On Sun, 2011-02-27 at 16:33 +0000, Ed W wrote:

> I think what you are saying is that using PIC requires some special 
> handling (but that work seems largely done now?).  However, does 
> removing PIC leave the AMD64 architecture "less secure" in some way? Or 
> is some other procedure now replacing PIC?

You can't "remove PIC" from AMD64 -- it's required for shared library
use.  But it's also built in to the AMD64 ABI, unlike x86 where it was
shoehorned into the existing ABI (by hijacking a register for the GOT).
So the USE flag doesn't actually serve any purpose.

Even worse, some packages disable parts of their code written in
assembler when USE=pic (since it fails when the extra register is taken
away), but would be fine under AMD64 with tons of extra registers.

Basically, the pic USE flag is only really useful, needed, or productive
on x86, so they're taking it out of the amd64 profile.

Re: [gentoo-hardened] Remove the pic use flag in the hardened amd64 profile.

["Tóth Attila"]

2011.Február 27.(V) 17:33 időpontban Ed W ezt írta:
> On 27/02/2011 08:20, klondike wrote:
>> 2011/2/27 Ed W<lists@wildgooses.com>:
>>> On 26/02/2011 18:01, Magnus Granberg wrote:
>>>> If you have read the last meeting we will be removing the pic use flag
>>>> as
>>>> default on in the hardened amd64 profile. We will start with the
>>>> changes
>>>> when
>>>> the new structure to the profiles have settled down.
>>> Hi, any chance of a bit of background on this change?  ie the "why" and
>>> some
>>> of the implications?
>> Summing it up a lot, amd64 usually needs not special  asm code for PIC
>> due to the way the ABI is defined (which means being PIC by default
>> usually).
>>
>> That's not always the case, i.e. aircrack needed special PIC code, but
>> in general it shouldn't be a problem.
>>
>
> Sorry to probe further, but I'm not getting the big picture (durr)
>
> I think what you are saying is that using PIC requires some special
> handling (but that work seems largely done now?).  However, does
> removing PIC leave the AMD64 architecture "less secure" in some way? Or

Using the ABI produces PIC-aware code in most cases without any special
treatment.

> is some other procedure now replacing PIC?
>
> My minimal understanding is that PIC is a key part of the address space
> randomisation that is considered useful for system hardening. Where does
> removing PIC leave us in that process?

Removing PIC won't result in non-PIC code on amd64 in most cases.

Dw.

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[pageexec]

On 27 Feb 2011 at 9:53, Anthony G. Basile wrote:

> >> Most of the asm code is in libs and on amd64 it need to be PIC friendly
> >> from
> >> the start. We don't need to disable asm code. We do that most times with
> >> the
> >> pic use flag on hardened profile.
> >>
> >> /Magnus

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).

at the same time to recover some performance we had a project to fix all the
position dependent asm code in all the multimedia and other libs (you can still
find some lingering patches in bugzilla from me), but unfortunately some never
made it upstream (some of them are even openly 'hostile' to PIC and went as far
as removing what little PIC they had or had unreasonable constraints like supporting
long-dead gcc versions).

so even if right now getting PIC requires using C code instead of (badly written)
asm, it doesn't have to be this way. if anyone wants to take this up again, talk
to me and i can point you at the patches i have (ffmpeg, xvid, xine are the really
big ones) and the gentoo docs written about the topic.

> An example of where it does is an attempt to defeat address space
> randomization by brute force.  32-bit address space is only 4G which is
> not impossibly large for success by brute force while 64-bits is about
> 10^19.  A lot harder.

that's only theory ;), in practice CPUs don't implement all 64 virtual bits,
e.g., on amd64 you have 'only' 48 bits (normally split into two 47 bit halves
for userland/kernel, except for UDEREF where userland gets only 42).

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Daniel Reidy]

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?

-dan

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Matthew Thode]

From what I can tell here, pic is nearly built in to amd64.  It should
be used by default on amd64 and I think it has to be explicitly
disabled (ffmpeg).  So, you can run -pic on all amd64 and get nearly
the same result as +pic on amd64.

-- Prometheanfire

On Mon, Feb 28, 2011 at 15:39, Daniel Reidy <dubkat@gmail.com> 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?
>
> -dan
>
>

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Marcel Meyer]

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? What happens 
when I use a 64-bit hardened dom0-kernel on Xen underneath (since the machine 
has more than 4 GB RAM, each VM won't get that much)?

Is the gain of security in this case worth the loss of randomization for ASLR?


Thank you

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[pageexec]

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 ;).

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[pageexec]

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, in HVM mode
i386 should be fine, amd64 should be dead slow.

> What happens when I use a 64-bit hardened dom0-kernel on Xen underneath

there's no such thing as a hardened dom0 kernel ;). some support for dom0
got into very recent linux kernels, but i never looked at what PaX support
would need also i believe some PaX features would require hypervisor changes
as well. in short, it's not going to happen anytime soon.

> Is the gain of security in this case worth the loss of randomization for ASLR?

falling back to domU, this question can only be answered by you (i.e., there
is no generic answer), but i'd say that in general the few bits lost in ASLR
are not at all important for security (ASLR is obfuscation, not real security
to begin with). the deal breaker for UDEREF/amd64 is really the performance
impact, that's what you should evaluate.

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Anthony G. Basile]

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.

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

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Anthony G. Basile]

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

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[pageexec]

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...

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Mike Edenfield]

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 :)

Re: [gentoo-hardened] Re: Re: Remove the pic use flag in the hardened amd64 profile.

[pageexec]

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...

[gentoo-hardened] Re: Re: Remove the pic use flag in the hardened amd64 profile.

[Peter Hjalmarsson]

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?

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

[Anthony G. Basile]

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