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-26-2011, 05:01 PM
Magnus Granberg
 
Default Remove the pic use flag in the hardened amd64 profile.

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)
 
Old 02-27-2011, 07:13 AM
Ed W
 
Default Remove the pic use flag in the hardened amd64 profile.

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
 
Old 02-27-2011, 07:20 AM
klondike
 
Default Remove the pic use flag in the hardened amd64 profile.

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.
 
Old 02-27-2011, 08:11 AM
Ryan Hill
 
Default Remove the pic use flag in the hardened amd64 profile.

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
 
Old 02-27-2011, 11:54 AM
Magnus Granberg
 
Default Remove the pic use flag in the hardened amd64 profile.

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

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?
>
 
Old 02-27-2011, 01:53 PM
"Anthony G. Basile"
 
Default Remove the pic use flag in the hardened amd64 profile.

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

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

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

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:
 

Thread Tools




All times are GMT. The time now is 07:12 AM.

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