On Tue, Oct 27, 2009 at 11:51:35PM +0100, Bastian Blank wrote:
> What would be a step forward:
[...]
> - Make any code PIC, including binaries (PIE) and static libs.
static libs would need to be PIE, not PIC.
This is something that's not properly supported on all our arches.
Some people will also say it's too big a performance impact.
Kurt
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-25-2009, 11:29 PM
Kurt Roeckx
Switch on compiler hardening defaults
On Tue, Oct 27, 2009 at 11:51:35PM +0100, Bastian Blank wrote:
> What would be a step forward:
[...]
> - Make any code PIC, including binaries (PIE) and static libs.
static libs would need to be PIE, not PIC.
This is something that's not properly supported on all our arches.
Some people will also say it's too big a performance impact.
Kurt
--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-26-2009, 09:45 AM
Bastian Blank
Switch on compiler hardening defaults
On Sat, Dec 26, 2009 at 01:29:48AM +0100, Kurt Roeckx wrote:
> On Tue, Oct 27, 2009 at 11:51:35PM +0100, Bastian Blank wrote:
> > What would be a step forward:
> > - Make any code PIC, including binaries (PIE) and static libs.
> static libs would need to be PIE, not PIC.
The differences between PIC and PIE are small. For all relevant
architectures the only difference is to enable the shared libs
assumptions for fPIC.
> This is something that's not properly supported on all our arches.
> Some people will also say it's too big a performance impact.
I would only change this setting on a per-arch basis. It needs an
additional register, but on most arches that should make no visible
difference.
--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-26-2009, 09:45 AM
Bastian Blank
Switch on compiler hardening defaults
On Sat, Dec 26, 2009 at 01:29:48AM +0100, Kurt Roeckx wrote:
> On Tue, Oct 27, 2009 at 11:51:35PM +0100, Bastian Blank wrote:
> > What would be a step forward:
> > - Make any code PIC, including binaries (PIE) and static libs.
> static libs would need to be PIE, not PIC.
The differences between PIC and PIE are small. For all relevant
architectures the only difference is to enable the shared libs
assumptions for fPIC.
> This is something that's not properly supported on all our arches.
> Some people will also say it's too big a performance impact.
I would only change this setting on a per-arch basis. It needs an
additional register, but on most arches that should make no visible
difference.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-06-2010, 12:20 AM
Kees Cook
Switch on compiler hardening defaults
On Thu, Dec 24, 2009 at 12:23:01PM +0100, Stefan Fritsch wrote:
> On Thu, 24 Dec 2009, Kees Cook wrote:
> >>>With the new package, the arch-specific logic for hardening defaults
> >>>is in one place, and a maintainer can selectively disable anything they
> >>>don't want on by default.
> >>
> >>This might be a good compromise to get network services hardened
> >>without changing the default build system. Is there a plan for which
> >
> >That's certainly a viable plan. This is kind of the approach we took in
> >Ubuntu for the PIE feature. We also considered packages with a less than
> >stellar security history. The list of packages built with PIE in Ubuntu
> >is: (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/BuiltPIE )
> >
> >amavisd-new apache2 asterisk bind9 cups cyrus-sasl2 dhcp3 dovecot exim4
> >ipsec-tools mysql-dfsg-5.1 nagios3 nagios-plugins ntp openbsd-inetd
> >openldap openssh postfix postgreqsl-8.3 samba sendmail squid wireshark
> >xinetd
>
> The problem with PIE is that it is not supported by Debian's gdb
> (#346409). That's why I disabled it again for apache2.
There is a maintained (by RedHat) patch for dealing with PIE. I already
maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
the gdb maintainer doesn't want it until it's in upstream. I, obviously,
think that's ridiculous. PIE works and is useful. Blocking its rollout
because gdb's support for it isn't upstream just furthers the catch-22.
> IIRC, there were also some apps (python?) that have performance
> problems with PIE. Therefore, PIE should not be switched on by
> default yet.
Yes, some programs show slow-down on i386 and other architectures with
limited registers. Those packages are exceptions, and should just
disable PIE in their build when they add hardening-includes:
DEB_BUILD_HARDENING_PIE:=0
-Kees
--
Kees Cook @debian.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-06-2010, 02:01 AM
Paul Wise
Switch on compiler hardening defaults
On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook <kees@debian.org> wrote:
> There is a maintained (by RedHat) patch for dealing with PIE. *I already
> maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
> the gdb maintainer doesn't want it until it's in upstream. *I, obviously,
> think that's ridiculous. *PIE works and is useful. *Blocking its rollout
> because gdb's support for it isn't upstream just furthers the catch-22.
It is perfectly reasonable to reject patches until they are upstream.
I personally will never add patches to Debian without either
committing them upstream myself or some indication that they already
have been or will be accepted upstream. IIRC the Debian kernel team
has similar policies. Why hasn't RedHat upstreamed the patch? They are
usually good about doing that. Perhaps you could push them to do so.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-06-2010, 03:05 AM
Michael Gilbert
Switch on compiler hardening defaults
On Wed, 6 Jan 2010 11:01:01 +0800 Paul Wise wrote:
> On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook <kees@debian.org> wrote:
>
> > There is a maintained (by RedHat) patch for dealing with PIE. *I already
> > maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
> > the gdb maintainer doesn't want it until it's in upstream. *I, obviously,
> > think that's ridiculous. *PIE works and is useful. *Blocking its rollout
> > because gdb's support for it isn't upstream just furthers the catch-22.
>
> It is perfectly reasonable to reject patches until they are upstream.
> I personally will never add patches to Debian without either
> committing them upstream myself or some indication that they already
> have been or will be accepted upstream. IIRC the Debian kernel team
> has similar policies. Why hasn't RedHat upstreamed the patch? They are
> usually good about doing that. Perhaps you could push them to do so.
While normally I would agree with your logic, when it comes to security
I think a more cautious logic must prevail. Remember that item 4 of
the social contract states that: "Our priorities are our users and free
software." An aspect of that guidance is providing high quality
security for those users. Hence, when a feature improves security (or
provides additional harding) the convenience factor of not differing
from upstream should be considered a lower priority than normal.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-06-2010, 03:37 AM
Kees Cook
Switch on compiler hardening defaults
Hi,
On Wed, Jan 06, 2010 at 11:01:01AM +0800, Paul Wise wrote:
> On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook <kees@debian.org> wrote:
>
> > There is a maintained (by RedHat) patch for dealing with PIE. *I already
> > maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
> > the gdb maintainer doesn't want it until it's in upstream. *I, obviously,
> > think that's ridiculous. *PIE works and is useful. *Blocking its rollout
> > because gdb's support for it isn't upstream just furthers the catch-22.
>
> It is perfectly reasonable to reject patches until they are upstream.
> I personally will never add patches to Debian without either
> committing them upstream myself or some indication that they already
> have been or will be accepted upstream. IIRC the Debian kernel team
> has similar policies. Why hasn't RedHat upstreamed the patch? They are
> usually good about doing that. Perhaps you could push them to do so.
Normally, I'd totally agree. I do not know why RedHat has chosen to carry
the PIE patches for 5 years[1], but they have. I[2] and others[3]
have asked over the years, but no one with a deep enough understanding
of the affected code has had the time to get it upstream.
That said, the patches[4] in RedHat have a full test-suite associated with
them. They're applied after their massive Archer patchset[5], so I had to
fiddle pretty hard to get the PIE support working in the Debian package.
As seen at the end of the Ubuntu gdb series file:
# RH stack that seems to be needed for sane PIE handling
gdb-6.3-test-pie-20050107.patch
gdb-6.5-bz203661-emit-relocs.patch
gdb-workaround-rh-stack-on.patch
gdb-6.6-buildid-locate.patch
gdb-6.3-pie-20050110.patch
gdb-workaround-rh-stack-off.patch
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-06-2010, 07:28 AM
Paul Wise
Switch on compiler hardening defaults
On Wed, Jan 6, 2010 at 12:37 PM, Kees Cook <kees@debian.org> wrote:
> On Wed, Jan 06, 2010 at 11:01:01AM +0800, Paul Wise wrote:
>> On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook <kees@debian.org> wrote:
>>
>> > There is a maintained (by RedHat) patch for dealing with PIE. *I already
>> > maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
>> > the gdb maintainer doesn't want it until it's in upstream. *I, obviously,
>> > think that's ridiculous. *PIE works and is useful. *Blocking its rollout
>> > because gdb's support for it isn't upstream just furthers the catch-22.
>>
>> It is perfectly reasonable to reject patches until they are upstream.
>> I personally will never add patches to Debian without either
>> committing them upstream myself or some indication that they already
>> have been or will be accepted upstream. IIRC the Debian kernel team
>> has similar policies. Why hasn't RedHat upstreamed the patch? They are
>> usually good about doing that. Perhaps you could push them to do so.
>
> Normally, I'd totally agree. *I do not know why RedHat has chosen to carry
> the PIE patches for 5 years[1], but they have. *I[2] and others[3]
> have asked over the years, but no one with a deep enough understanding
> of the affected code has had the time to get it upstream.
>
> That said, the patches[4] in RedHat have a full test-suite associated with
> them. *They're applied after their massive Archer patchset[5], so I had to
> fiddle pretty hard to get the PIE support working in the Debian package.
>
> As seen at the end of the Ubuntu gdb series file:
>
> # RH stack that seems to be needed for sane PIE handling
> gdb-6.3-test-pie-20050107.patch
> gdb-6.5-bz203661-emit-relocs.patch
> gdb-workaround-rh-stack-on.patch
> gdb-6.6-buildid-locate.patch
> gdb-6.3-pie-20050110.patch
> gdb-workaround-rh-stack-off.patch
>
> -Kees
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=130423
> [2] http://sourceware.org/ml/gdb-patches/2008-05/msg00269.html
> [3] http://sourceware.org/ml/gdb/2006-08/msg00188.html
> [4] http://cvs.fedora.redhat.com/viewvc/devel/gdb/
> [5] http://fedoraproject.org/wiki/Features/Archer
Hmm, OK. I'm quite surprised Fedora carries so many[1] patches to GDB,
given their policy of staying close to upstreams[2].
Jan, as the maintainer of GDB in Fedora, can you comment on if/when
Fedora's many many GDB patches (particularly PIE support) will be
merged upstream? Has there been any attempt thus far at getting them
merged? It would also be nice if the patches had some metadata in
them, such as what is described in DEP-3.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-06-2010, 07:29 AM
Paul Wise
Switch on compiler hardening defaults
On Wed, Jan 6, 2010 at 4:28 PM, Paul Wise <pabs@debian.org> wrote:
> On Wed, Jan 6, 2010 at 12:37 PM, Kees Cook <kees@debian.org> wrote:
>> On Wed, Jan 06, 2010 at 11:01:01AM +0800, Paul Wise wrote:
>>> On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook <kees@debian.org> wrote:
>>>
>>> > There is a maintained (by RedHat) patch for dealing with PIE. *I already
>>> > maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
>>> > the gdb maintainer doesn't want it until it's in upstream. *I, obviously,
>>> > think that's ridiculous. *PIE works and is useful. *Blocking its rollout
>>> > because gdb's support for it isn't upstream just furthers the catch-22.
>>>
>>> It is perfectly reasonable to reject patches until they are upstream.
>>> I personally will never add patches to Debian without either
>>> committing them upstream myself or some indication that they already
>>> have been or will be accepted upstream. IIRC the Debian kernel team
>>> has similar policies. Why hasn't RedHat upstreamed the patch? They are
>>> usually good about doing that. Perhaps you could push them to do so.
>>
>> Normally, I'd totally agree. *I do not know why RedHat has chosen to carry
>> the PIE patches for 5 years[1], but they have. *I[2] and others[3]
>> have asked over the years, but no one with a deep enough understanding
>> of the affected code has had the time to get it upstream.
>>
>> That said, the patches[4] in RedHat have a full test-suite associated with
>> them. *They're applied after their massive Archer patchset[5], so I had to
>> fiddle pretty hard to get the PIE support working in the Debian package.
>>
>> As seen at the end of the Ubuntu gdb series file:
>>
>> # RH stack that seems to be needed for sane PIE handling
>> gdb-6.3-test-pie-20050107.patch
>> gdb-6.5-bz203661-emit-relocs.patch
>> gdb-workaround-rh-stack-on.patch
>> gdb-6.6-buildid-locate.patch
>> gdb-6.3-pie-20050110.patch
>> gdb-workaround-rh-stack-off.patch
>>
>> -Kees
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=130423
>> [2] http://sourceware.org/ml/gdb-patches/2008-05/msg00269.html
>> [3] http://sourceware.org/ml/gdb/2006-08/msg00188.html
>> [4] http://cvs.fedora.redhat.com/viewvc/devel/gdb/
>> [5] http://fedoraproject.org/wiki/Features/Archer
>
> Hmm, OK. I'm quite surprised Fedora carries so many[1] patches to GDB,
> given their policy of staying close to upstreams[2].
>
> Jan, as the maintainer of GDB in Fedora, can you comment on if/when
> Fedora's many many GDB patches (particularly PIE support) will be
> merged upstream? Has there been any attempt thus far at getting them
> merged? It would also be nice if the patches had some metadata in
> them, such as what is described in DEP-3.
>
> 1. http://cvs.fedoraproject.org/viewvc/rpms/gdb/devel/
> 2. http://fedoraproject.org/wiki/Staying_close_to_upstream_projects
> 3. http://dep.debian.net/deps/dep3/
Bah, actually CCing this time.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Switch on compiler hardening defaults
