On 16 April 2012 11:39, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>
> With more and more distros and even android employing gccs -fpie for
> building packages, should Arch consider enabling it.
>
> For my users it would mean less programs being killed by the
> grsecurity kernel due to text relocation attempts. No complaints yet as
> I have a sandboxed flash browser but eventually there may be one about
> x264/mp4.
>
> For everyone else it would mean a more secure system due to better use
> of ASLR.
>
> Are complications like static binaries an issue arch simply hasn't the
> time to deal with (does gcc work around them automatically now?) and do
> users care more about adding upto a few seconds to the start up time of
> some programs on x86 over security?

I'm against using PIC for executables, since it hursts speed
(especially on 32bit).

Lukas

On Mon, 16 Apr 2012 11:58:36 +0200
Lukáš Jirkovský wrote:

> (especially on 32bit).


Slightly on 32bit and almost no difference on 64bit. OpenBSD uses PIEs
everywhere and my x86 users say everythings much quicker than Windows.

Fair enough though as long as you do have a good understanding of the
real difference to users. I'm quite happy, it would just be better all
round.

Phones have very litle resources and despite the bull that many believe,
an x86 cycle is not even close to an arm cycle and yet Android now
uses PIE for better ASLR. Please don't bring up geekbench or coremark
as that's a crock for cross architecture if you look at the stated
caveats by coremark or details and results by geekbench. Your better of
measuring in time to accomplish something.

I read in a forum which was completely unsubstantiated that Google
avoided PIE for chrome due to javascript speed. Chromium runs just fine
on OpenBSD also.

Alpine uses ulibc for size and speed and still PIE.

On Mon, 16 Apr 2012 15:37:13 +0100
Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

> On Mon, 16 Apr 2012 11:58:36 +0200
> Lukáš Jirkovský wrote:
>
> > (especially on 32bit).
>
>
> Slightly on 32bit and almost no difference on 64bit. OpenBSD uses PIEs
> everywhere and my x86 users say everythings much quicker than Windows.
>
> Fair enough though as long as you do have a good understanding of the
> real difference to users. I'm quite happy, it would just be better all
> round.
>
> Phones have very litle resources and despite the bull that many believe,
> an x86 cycle is not even close to an arm cycle and yet Android now
> uses PIE for better ASLR. Please don't bring up geekbench or coremark
> as that's a crock for cross architecture if you look at the stated
> caveats by coremark or details and results by geekbench. Your better of
> measuring in time to accomplish something.
>
> I read in a forum which was completely unsubstantiated that Google
> avoided PIE for chrome due to javascript speed. Chromium runs just fine
> on OpenBSD also.
>
> Alpine uses ulibc for size and speed and still PIE.

+1 for all arches. However, some programs will fail to build straightforwadly,
e.g. evince, cpupower, claws-mail.

--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On 17/04/12 00:37, Kevin Chadwick wrote:
> On Mon, 16 Apr 2012 11:58:36 +0200
> Lukáš Jirkovský wrote:
>
>> (especially on 32bit).
>
>
> Slightly on 32bit and almost no difference on 64bit. OpenBSD uses PIEs
> everywhere and my x86 users say everythings much quicker than Windows.
>

Care to define "slightly"... I looked into this when we added some
hardening to our default CFLAGS and the benchmarks I found indicated
that adding PIE to 32bit added a 5-10% performance hit.

My suggestion would be for maintainers of various applications that
warrant this security (openssh, apache, samba, firefox...) to manually
enable it. We could make PIE the default for x86_64.

Allan

On Tue, 17 Apr 2012 08:49:21 +1000
Allan McRae wrote:

> > Slightly on 32bit and almost no difference on 64bit. OpenBSD uses PIEs
> > everywhere and my x86 users say everythings much quicker than Windows.
> >
>
> Care to define "slightly"... I looked into this when we added some
> hardening to our default CFLAGS and the benchmarks I found indicated
> that adding PIE to 32bit added a 5-10% performance hit.

That's the figure that's in all the forums.

Does that happen for all programs, I'm under the impression not but
could be very wrong?

Would you actually notice the 5-10%?

As I say, I didn't notice on OpenBSD and there would be a larger slow
down for programs that had to run dbus before they ran the first time
as I didn't start it during boot.

I'd be more concerned about having to deal with fallout myself which
I believe would apply to 64 bit too?

I see the security as more important especially as any speed sensitive
app user could recompile that one app.

If you've already looked into it and decided then, cool. It looks like
ubuntu are selectively enabling/disabling it and looking into it more
at the moment.

On Tue, 17 Apr 2012 08:49:21 +1000
Allan McRae <allan@archlinux.org> wrote:

> On 17/04/12 00:37, Kevin Chadwick wrote:
> > On Mon, 16 Apr 2012 11:58:36 +0200
> > Lukáš Jirkovský wrote:
> >
> >> (especially on 32bit).
> >
> >
> > Slightly on 32bit and almost no difference on 64bit. OpenBSD uses PIEs
> > everywhere and my x86 users say everythings much quicker than Windows.
> >
>
> Care to define "slightly"... I looked into this when we added some
> hardening to our default CFLAGS and the benchmarks I found indicated
> that adding PIE to 32bit added a 5-10% performance hit.
>
> My suggestion would be for maintainers of various applications that
> warrant this security (openssh, apache, samba, firefox...) to manually
> enable it. We could make PIE the default for x86_64.
>
> Allan
>

+1 for the default -fPIE on 64bit. Probably LDFLAGS will also have to
be appended with -z,now like they do in ubuntu...

--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Impossible to implement without patching toolchain defaults (Never
going to happen) or wrapping the compiler.

Fedora/Ubuntu handle it on a per-package basis.