FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 02-27-2011, 03:33 PM
Ed W
 
Default Remove the pic use flag in the hardened amd64 profile.

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
 
Old 02-27-2011, 05:49 PM
Mike Edenfield
 
Default Remove the pic use flag in the hardened amd64 profile.

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.
 
Old 02-27-2011, 06:09 PM
"Tóth Attila"
 
Default Remove the pic use flag in the hardened amd64 profile.

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.
 
Old 02-27-2011, 09:58 PM
 
Default Remove the pic use flag in the hardened amd64 profile.

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).
 
Old 02-28-2011, 07:39 PM
Daniel Reidy
 
Default Remove the pic use flag in the hardened amd64 profile.

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
 
Old 02-28-2011, 08:07 PM
Matthew Thode
 
Default Remove the pic use flag in the hardened amd64 profile.

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
>
>
 
Old 03-01-2011, 02:52 PM
Marcel Meyer
 
Default Remove the pic use flag in the hardened amd64 profile.

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
 
Old 03-01-2011, 07:02 PM
 
Default Remove the pic use flag in the hardened amd64 profile.

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 .
 
Old 03-01-2011, 07:08 PM
 
Default Remove the pic use flag in the hardened amd64 profile.

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, "Tth 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.
 
Old 03-01-2011, 10:22 PM
"Anthony G. Basile"
 
Default Remove the pic use flag in the hardened amd64 profile.

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
 

Thread Tools




All times are GMT. The time now is 07:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org