Re: Porter roll call for Debian Stretch

[Ben Hutchings]

On Sat, 2016-10-01 at 15:48 +0200, John Paul Adrian Glaubitz wrote:
> On 10/01/2016 02:17 PM, Ben Hutchings wrote:
> > 
> > > 
> > > This isn't the case for PowerPC32 where upstream development is still very
> > > active because it's part of the PowerPC kernel which is maintained by
> > > IBM.
> > 
> > This is not at all true.  My experience is that IBM doesn't even build-
> > test 32-bit configurations, as evidenced by several stable updates
> > causing FTBFS in Debian.
> 
> They care enough that they are fixing bugs. Just recently, a bug in the
> PowerPC kernel was fixed that affected 32-bit embedded PowerPCs only.

$ git log --author=ibm --grep='ppc-?32|powerpc-?32|32-bit' -i -E arch/powerpc

finds me fewer than ten commits per year.

> > 
> > > 
> > > As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> > > support, so even SPARC is getting back into shape which is why I hope
> > > we can add sparc64 as an official port soon.
> > [...]
> > 
> > Oracle cares about Solaris on SPARC, not Linux on SPARC.
> 
> Well, then you know more than the people at Oracle that I am talking to.
[... much evidence of Oracle supporting Linux on SPARC ...]

OK, I accept this has changed, but I'm quite surprised - Oracle is
ruthlessly commercial, and I'm mystified as to who they expect to buy
it.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.

signature.asc
Description: This is a digitally signed message part

Re: Porter roll call for Debian Stretch

[Ben Hutchings]

On Fri, 2016-09-30 at 22:34 +0200, John Paul Adrian Glaubitz wrote:
> On 09/30/2016 09:04 PM, Niels Thykier wrote:
> > 
> > As for "porter qualification"
> > =
> > 
> > We got burned during the Jessie release, where a person answered the
> > roll call for sparc and we kept sparc as a release architecture for
> > Jessie.  However, we ended up with a completely broken and unbootable
> > sparc kernel.
> 
> To be fair, this happened because the upstream kernel development for
> SPARC came to an almost complete stop. There was basically only David
> Miller working on the port which turned out not to be enough.
> 
> This isn't the case for PowerPC32 where upstream development is still very
> active because it's part of the PowerPC kernel which is maintained by
> IBM.

This is not at all true.  My experience is that IBM doesn't even build-
test 32-bit configurations, as evidenced by several stable updates
causing FTBFS in Debian.

> PowerPC32 is also still quite popular which is why it still sees
> quite some testing in the wild. There are still new PowerPC32 designs
> based on embedded CPUs (FreeScale and the like).

Which are very different from the Power Macs and similar platforms that
most Debian powerpc users care about.

> As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> support, so even SPARC is getting back into shape which is why I hope
> we can add sparc64 as an official port soon.
[...]

Oracle cares about Solaris on SPARC, not Linux on SPARC.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part

Re: Porter roll call for Debian Stretch

[Ben Hutchings]

On Sat, 2016-10-01 at 02:28 +0200, Adam Borowski wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
[...]
> > I have not heard from the ppc64el porters, but I suspect ppc64 will
> > not be a release arch. So you need to take into consideration that for
> > powerpc to remain a release arch, one need minimal working ppc64 port.
> > Could we solve the situation of ppc64 for Stretch, could it be moved
> > to official release arch ?
> 
> What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
> kernels so users don't need multiarch:
[...]

This is only the case because ppc64 has a lower level of support
(unofficial port) than powerpc (release architecture).  The 64-bit
kernel package should be dropped once powerpc is at the same or lower
level of support than ppc64 - just as we've done for i386, s390 and
sparc.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

On Sat, Oct 1, 2016 at 2:28 AM, Adam Borowski  wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
>> On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
>>  wrote:
>> [...]
>> > On the other hand, some packages dropped support for PowerPC32 like Mono
>> > but this isn't a concern for most users, I would say.
>> [...]
>>
>> However I need to mention that the specific ppc/mono issue is in fact
>> pretty interesting. The long thread is on debian-powerpc@l.d.o but the
>> short version is that this issue only happen because we build the
>> ppc32 mono version on a ppc64 kernel, I know that since I did debug
>> this issue.
>
> Which, if I read the bug correctly, is a yet another case of a bogus
> build system looking at characteristics of the machine it's compiled on
> rather than baseline of the arch.

Well the bug is really upstream: one cannot assume page size at
compilation time. But that is a different story.

> And, per your own work, it's +patch +fixed-upstream.

Wow ! In fact I just realize my patch was against git/master at the
time, and was never backported. Need to get this fixed ASAP.

>> I have not heard from the ppc64el porters, but I suspect ppc64 will
>> not be a release arch. So you need to take into consideration that for
>> powerpc to remain a release arch, one need minimal working ppc64 port.
>> Could we solve the situation of ppc64 for Stretch, could it be moved
>> to official release arch ?
>
> What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
> kernels so users don't need multiarch:
>
> powerpc has:
> linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed)
> i386 has:
> linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs
> linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs
> linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity 
> protection
> linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed)
> linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed)
>
> Note the joke: "for modern PCs".  Unless you do embedded it takes some
> serious dumpster diving to find a machine not better served by an -amd64
> kernel (and thus multiarch).  The i386 architecture is not self-contained,
> powerpc is.
>
> Thus, there is no need for ppc64 (userland), as long as powerpc has the
> toolchain to build 64-bit kernels.  And that's a primary target for gcc
> upstream.

Great ! That's all I wanted to check. I was worried we would need
buildd(s) running on ppc64el.

Re: Porter roll call for Debian Stretch

[Adam Borowski]

On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
> On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
>  wrote:
> [...]
> > On the other hand, some packages dropped support for PowerPC32 like Mono
> > but this isn't a concern for most users, I would say.
> [...]
> 
> However I need to mention that the specific ppc/mono issue is in fact
> pretty interesting. The long thread is on debian-powerpc@l.d.o but the
> short version is that this issue only happen because we build the
> ppc32 mono version on a ppc64 kernel, I know that since I did debug
> this issue.

Which, if I read the bug correctly, is a yet another case of a bogus
build system looking at characteristics of the machine it's compiled on
rather than baseline of the arch.

And, per your own work, it's +patch +fixed-upstream.

> I have not heard from the ppc64el porters, but I suspect ppc64 will
> not be a release arch. So you need to take into consideration that for
> powerpc to remain a release arch, one need minimal working ppc64 port.
> Could we solve the situation of ppc64 for Stretch, could it be moved
> to official release arch ?

What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
kernels so users don't need multiarch:

powerpc has:
linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC (signed)
linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC 
(signed)
linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed)
i386 has:
linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs
linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs
linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity 
protection
linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed)
linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed)

Note the joke: "for modern PCs".  Unless you do embedded it takes some
serious dumpster diving to find a machine not better served by an -amd64
kernel (and thus multiarch).  The i386 architecture is not self-contained,
powerpc is.

Thus, there is no need for ppc64 (userland), as long as powerpc has the
toolchain to build 64-bit kernels.  And that's a primary target for gcc
upstream.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: Porter roll call for Debian Stretch

[Milan Kupcevic]

On 09/20/2016 05:46 PM, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.
> 


Thank you Adrian for stepping up. You will have my support in this
endeavor for the Stretch release.

Milan




signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

Adrian,

On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
 wrote:
[...]
> On the other hand, some packages dropped support for PowerPC32 like Mono
> but this isn't a concern for most users, I would say.
[...]

Thanks very much for stepping up as porter, you have my vote !

However I need to mention that the specific ppc/mono issue is in fact
pretty interesting. The long thread is on debian-powerpc@l.d.o but the
short version is that this issue only happen because we build the
ppc32 mono version on a ppc64 kernel, I know that since I did debug
this issue.

I have not heard from the ppc64el porters, but I suspect ppc64 will
not be a release arch. So you need to take into consideration that for
powerpc to remain a release arch, one need minimal working ppc64 port.
Could we solve the situation of ppc64 for Stretch, could it be moved
to official release arch ?

-M

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/30/2016 09:04 PM, Niels Thykier wrote:
> As for "porter qualification"
> =
> 
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie.  However, we ended up with a completely broken and unbootable
> sparc kernel.

To be fair, this happened because the upstream kernel development for
SPARC came to an almost complete stop. There was basically only David
Miller working on the port which turned out not to be enough.

This isn't the case for PowerPC32 where upstream development is still very
active because it's part of the PowerPC kernel which is maintained by
IBM. PowerPC32 is also still quite popular which is why it still sees
quite some testing in the wild. There are still new PowerPC32 designs
based on embedded CPUs (FreeScale and the like).

As for SPARC, Oracle is actually now heavily investing in Linux SPARC
support, so even SPARC is getting back into shape which is why I hope
we can add sparc64 as an official port soon.

>   That was an embarrassment to the Debian stability and quality
>   reputation that I never - ever - want to repeat.

Well, mistakes happen and while I think it's good and important to learn
from mistakes, we should not dramatize such issues. We have had worse
issues like the OpenSSL entropy bug, for example, and we still managed
to cope with the fallout in a very professional manner.

> (For avoidance of doubt: I want to ensure that release architectures
> "just work(tm)" and I have no desire to blame that volunteer).

I don't think there is any concern regarding the powerpc port in this
regard. wanna-build shows almost 11800 packages that are up-to-date
which is a good indicator that the port is in good shape, both regarding
the toolchain and various source packages which need architecture-specific
adaptations like LibreOffice or JavaScript packages.

On the other hand, some packages dropped support for PowerPC32 like Mono
but this isn't a concern for most users, I would say.

> If I am to support powerpc as a realease architecture for Stretch, I
> need to know that there are *active* porters behind it committed to
> keeping it in the working.  People who would definitely catch such
> issues long before the release.  People who file bugs / submit patches etc.

I agree and I'm actually doing that all the time. I always run unstable
on my machines and constantly check wanna-build for build issues and
report them upstream whenever they occur. I have helped dozens of such
issues on "sh4" and "sparc64", for example.

> If you need inspiration: Have a look at the [automatic testing of
> ppc64el images].  Or the [arm64 machines on ci.debian.net] with
> comparable results to amd64.  This is the sort of thing that inspires
> confidence in the ports for me and I think we should have vastly more of.

I agree that would be nice to have. However, to be fair, we don't have
that type of testing for all release architectures and to my current
knowledge, automated testing of installation images is not a criteria
for an architecture to maintain release status.

My main argument for why we should keep the powerpc port is its
popularity. If we look at the numbers from popcon [1], powerpc
is still the fourth-most-popular port and I think we would disappoint
many users if we were to drop the port for Stretch. Note that while
ports like "arm64" or "ppc64el" receive lots of support, especially
from companies, they still haven't reached the same popularity as the
powerpc port for example. Heck, there are even more users for "hppa"
and "sparc64" which both are just unofficial ports architectures.

Thanks,
Adrian

> [1] http://popcon.debian.org/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Niels Thykier:
> [...]
> 
> As for "porter qualification"
> =
> 
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie.  However, we ended up with a completely broken and unbootable
> sparc kernel.
> 
>   That was an embarrassment to the Debian stability and quality
>   reputation that I never - ever - want to repeat.
> 
> (For avoidance of doubt: I want to ensure that release architectures
> "just work(tm)" and I have no desire to blame that volunteer).
> 
> 
> [...]
> 

I have been reminded of my inaccurate memory.  The broken sparc kernel
was released in Wheezy (and discovered during Jessie).  The roll call
for Jessie happened shortly after Wheezy release but before DSA
discovered the broken kernel.

Nonetheless, the core argument still stands.

Thanks,
~Niels

Re: Porter roll call for Debian Stretch

[Adam D. Barratt]

On Fri, 2016-09-30 at 19:04 +, Niels Thykier wrote:
> As for "porter qualification"
> =
> 
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie.  However, we ended up with a completely broken and unbootable
> sparc kernel.

fwiw, you mean wheezy.

Regards,

Adam

Re: Porter roll call for Debian Stretch

[Adam Borowski]

On Fri, Sep 30, 2016 at 10:03:47AM +0200, Mathieu Malaterre wrote:
> [Let's assume that we can't find a powerpc porter in time for Stretch.]

Two potential porters stepped up, who might or might not be accepted.

> 1. Will `powperpc` automatically be downgraded to simple port ? Or is
> this also not automated and the port may simply be removed (eg. sparc)
> ?

Removal from the main archive isn't automatic, and assuming no serious
kernel or toolchain breakage, I guess there's no reason for such removal
to be hasty.

On the other hand, place in -ports (aka second-class architectures) isn't
automatic either, and relies on someone doing the work.

> 2. Apart from loosing the automatic debian-installer stuff, what else
> are we going to loose in that scenario ?

Security support and stable release.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/30/2016 06:08 PM, Niels Thykier wrote:
> I strongly /suspect/ that "no porters" for powerpc will imply the
> removal of powerpc for Stretch.  It may or may not be moved to ports
> (assuming someone is willing to support it there).

So, I take this as a "no" for the offer from me and Christoph Biedel to take
over the powerpc port for Stretch?

I have quite some experience with working on ports and unlike what Matthias 
claimed,
I'm not just maintaining a few buildds but also getting architecture-specific 
bugs
fixed and so on.

Is there any specific qualification I am missing?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Mathieu Malaterre:
> Hi all,
> 
> [...]
> 
> [Let's assume that we can't find a powerpc porter in time for Stretch.]
> 
> 1. Will `powperpc` automatically be downgraded to simple port ? Or is
> this also not automated and the port may simply be removed (eg. sparc)
> ?
> 2. Apart from loosing the automatic debian-installer stuff, what else
> are we going to loose in that scenario ?
> 
> Thanks much for pointers !
> 
> -M
> 

I strongly /suspect/ that "no porters" for powerpc will imply the
removal of powerpc for Stretch.  It may or may not be moved to ports
(assuming someone is willing to support it there).

Not sure I can answer your 2nd question though.

~Niels

Re: Porter roll call for Debian Stretch

[Christian Zigotzky]

You have a porter for PowerPC. See email from Adrian. ;-)

-- Christian

Sent from my iPhone

> On 30 Sep 2016, at 10:03, Mathieu Malaterre  wrote:
> 
> Hi all,
> 
>> On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose  wrote:
>>> On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
 On 09/20/2016 11:16 PM, Niels Thykier wrote:
   - powerpc: No porter (RM blocker)
>>> 
>>> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
>>> maintaining powerpcspe which is very similar to powerpc.
>> 
>> No, you are not maintaining powerpcspe as a release architecture, and that's
>> something different than building packages for some of the ports 
>> architectures.
>> If you can get powerpcspe accepted as a release architecture, then maybe you
>> gain some credibility to maintain another release architecture ;)
> 
> [Let's assume that we can't find a powerpc porter in time for Stretch.]
> 
> 1. Will `powperpc` automatically be downgraded to simple port ? Or is
> this also not automated and the port may simply be removed (eg. sparc)
> ?
> 2. Apart from loosing the automatic debian-installer stuff, what else
> are we going to loose in that scenario ?
> 
> Thanks much for pointers !
> 
> -M
> 

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

Hi all,

On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose  wrote:
> On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
>> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>>- powerpc: No porter (RM blocker)
>>
>> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
>> maintaining powerpcspe which is very similar to powerpc.
>
> No, you are not maintaining powerpcspe as a release architecture, and that's
> something different than building packages for some of the ports 
> architectures.
> If you can get powerpcspe accepted as a release architecture, then maybe you
> gain some credibility to maintain another release architecture ;)

[Let's assume that we can't find a powerpc porter in time for Stretch.]

1. Will `powperpc` automatically be downgraded to simple port ? Or is
this also not automated and the port may simply be removed (eg. sparc)
?
2. Apart from loosing the automatic debian-installer stuff, what else
are we going to loose in that scenario ?

Thanks much for pointers !

-M

Re: Porter roll call for Debian Stretch

[Christoph Biedl]

John Paul Adrian Glaubitz wrote...

> On 09/20/2016 11:16 PM, Niels Thykier wrote:
> >- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.

For somewhat personal reasons I'm interested in keeping powerpc in
stretch as well. I certainly cannot take the entire role as a porter,
especially since I don't know what amount of work this implies. But I
am willing to help.

There are two powerpc boxes in my collection, used regulary. One runs
on stable, the other on testing. I haven't done d-i tests but
certainly could do.

Christoph



signature.asc
Description: Digital signature

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/23/2016 03:54 PM, Matthias Klose wrote:
> No, you are not maintaining powerpcspe as a release architecture, and that's
> something different than building packages for some of the ports 
> architectures.
> If you can get powerpcspe accepted as a release architecture, then maybe you
> gain some credibility to maintain another release architecture ;)

So, what are the criteria to be knighted to become a maintainer of powerpc?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Porter roll call for Debian Stretch

[Matthias Klose]

On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.

No, you are not maintaining powerpcspe as a release architecture, and that's
something different than building packages for some of the ports architectures.
If you can get powerpcspe accepted as a release architecture, then maybe you
gain some credibility to maintain another release architecture ;)

Matthias

Re: Porter roll call for Debian Stretch

[Christian Seiler]

On 09/21/2016 08:41 AM, Riku Voipio wrote:
> AFAIK Address space randomizing is not really helpful on 32 bit 
> architectures - there is just not that many places to randomize to[1].

Well, sure, but there's still a huge difference in an explot with
100% reliability, or an exploit that will just crash the program
in 95% of cases. Sure, if there's an easy way to repeatedly try
the exploit 20 times, it won't be a show-stopper, but it will
make the life of people who want to exploit a flaw just a tiny
bit harder.

> At least previously, PIE added ~10% to binary size,

At least on x86 there have been substantial improvements in
receent gcc versions when it comes to PIE support, so the impact
of PIE on executables even on 32bit is a lot smaller than it used
to be. I don't know about ARM though.

Consider the following two data points:

 - A _lot_ of code in Debian is in shared libraries, which are
   compiled with -fPIC anyway. Many executables only spend a
   fraction of their instructions in the executable code itself.

 - It's been considered best practice to enable PIE executables
   if possible (via hardening=+all or similar), so many programs
   in Debian (and e.g. all of my packages except one) already
   use that. I suspect that a lot of of code that you are
   currently running is already PIE, especially in the packages
   that are more actively maintained.

Regards,
Christian

Re: Porter roll call for Debian Stretch

[Riku Voipio]

On Tue, Sep 20, 2016 at 09:16:00PM +, Niels Thykier wrote:
> Over all, most people (who answered it) was positive towards the switch.
>  Based on this, I suspect that if we make PIE default in Stretch, then
> we will do it for all architectures.  That said, you will be notified if
> that default changes for Stretch.

Is this just for ASLR, or is ther another motivating factor for PIE?

AFAIK Address space randomizing is not really helpful on 32 bit 
architectures - there is just not that many places to randomize to[1].
At least previously, PIE added ~10% to binary size, which can have a major
performance impact on the 32-bit arm core's that don't have much cache to
begin with.

Riku
[1] https://cseweb.ucsd.edu/~hovav/dist/asrandom.pdf

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/20/2016 11:16 PM, Niels Thykier wrote:
>- powerpc: No porter (RM blocker)

I'd be happy to pick up powerpc to keep it for Stretch. I'm already
maintaining powerpcspe which is very similar to powerpc.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Niels Thykier]

ni...@thykier.net:
> Hi,
> 
> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 
>  [...]
> 

Thanks to all that replied to the roll call.

We got replies from all architectures except amd64 (Waived), i386
(Waived) and powerpc (problematic).  For the ports that replied, all had
at least 2 or more porters.
  We also got a parallel update from Matthias Klose on the toolchain
state[1].  Based on these we have updated the current state of the
architecture qualification for Stretch[2].

 * Please check that your name is listed as a porter on [2] (see [3]
   for how).  If I missed you, please do not hesitate to let me know.

 * For powerpc, mips and mipsel: Please note that we have added a
   (potentially) blocking issues for your architecture.
   - powerpc: No porter (RM blocker)
   - mips+mipsel: #834147 (RM concern, possibly blocker)


As for the piggy backed question about PIE by default:

 * arm64: 2 OK, 1 did not mention it
 * armel: 3 OK, 1 OK if tested first, 1 was neutral and 1 did not
   mention it
 * armhf: 4 OK, 1 OK if tested first, 1 was neutral and 2 did not
   mention it
 * mips+mipsel+mips64el: 3 OK, 1 OK later, 4 did not mention it.
 * ppc64el: 3 OK, 1 recommended further testing/research
 * s390x: 2 OK

Over all, most people (who answered it) was positive towards the switch.
 Based on this, I suspect that if we make PIE default in Stretch, then
we will do it for all architectures.  That said, you will be notified if
that default changes for Stretch.

Thanks,
~Niels

[1] https://lists.debian.org/debian-release/2016/09/msg00263.html

[2] https://release.debian.org/stretch/arch_qualify.html

[3] Hover your mouse over the number of porters for your architecture
or download the underlying data file from:
  https://release.debian.org/stretch/arch_spec.yaml




signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Roger Shimizu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 17 Aug 2016 22:05:06 +0200
ni...@thykier.net wrote:

> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For armel, I
 - submit device-tree patch to upstream (linux kernel), and backport to debian 
kernel to get more devices supported
 - support new device for d-i and flash-kernel package
 - test most packages on this architecture
 - run Debian stable / testing / unstable system on port that I use regularly
 - triage arch-specific bugs
 - fix arch-related bugs
 - triage d-i bugs
 - test d-i regularly
 - fix d-i bugs/issues

I am a DM.

Altough I enabled -fPIE/-pie for most of my maintaining packages, I'm not sure 
/ I don't have enough knowledge whether it's able to be applied to all packages.
Since all other ARM porters seem agree on this, I believe it definitely 
deserves a try to enable this hardening on stretch.

Cheers,
- -- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXzEFiAAoJEKR4aw2nAzSoAekP/j4eNf0jKvmArPlPbhA7XkBk
/5u9Un4qOHBNcSMAU5YVLHkpnT1CX/C08W+/ctGbB9AnnRwyn8X0uailjedZ13jK
oZYW/kUSwWiPmOkRTeNgFepzuKL+TNsAGgjHOY4ZbzYKC+h9C0UNWwyA77L3GUep
3HA9eTrtxMAAvJPNN4AhOjMeCI3qXIZ+wLKjhT+u/OUETWly8MolBw8PUjjwW6yy
Va7ciRMQf8KL149+Pa/tYFaENoAOV6//3M2QkJyaGbfxJp3xiFFcrlw+kw6J4RyH
vNIewz78nZwN88Y7JWa2EdBVcJr0897REXpDPXK/OpzlWw0R0xqB86jtmHfc+rQJ
IiNGt5Uc4Y3mD04O6AEDDJFJnEQ/QLi8OR8/TuxHiBJ6JTv0m67KsJVgdFqeRnlz
wJqcIQAzTF1iixVXjreVqW6P/+pGNHDbh9APfUz+UV97sZ4tD2BV1K1Rgk7cPDCn
zcpVhkQRy5PzLmK315vb8h9juFDDS/18yzmXwGMnmIhv4+8GBJIQLm5gvk9NuEbw
V/hBC42+fqX6RzGCoV3M8V+A6aLSpG/BcIAQOx8ewVfzMHIFSJmYParCHKXdiX+z
WB8UBt2xCHuzg98jxU80UwR492X9WvKeb6xA8dKqOW22XzsLxaQTe+SLSaGQ7er2
cpuhCpYFDKj/TL6UE2f9
=Vckg
-END PGP SIGNATURE-

Re: Porter roll call for Debian Stretch

[Guillem Jover]

Hi!

On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote:
> Kurt Roeckx:
> > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
> >>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
> >>also apply to this port? [0]
> > 
> > If -fPIE is the default will -fPIC override it?
> > 
> > It will also default to tell the linker to use -pie, but then
> > don't do it when you want to create a shared library?
> 
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.

As I mentioned on IRC, the Gentoo people seems to have done so as well
in their Gentoo Hardened Toolchain project
.

> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).

I think there are some bugs tracked in Fedora about this
, And this
is what I based the dpkg patch on as a potential alternative instead
of modifying our toolchain, which I think would be preferable. But see
below.

> >>From what I understand, depending on what the .o file is going to
> > be used for you want different things:
> > - shared library: -fPIC
> > - executable: -fPIC or -fPIE both work, but prefer -fPIE
> > - static library: Same as executables
> > 
> > For static libraries we now have a policy to not use -fPIC,
> > should that then get replaced by using -fPIE?

> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I think that's what we are getting right now for any package enabling
the "pie" build flags feature anyway.

> [1] Example spec files for this case seems to be something like:
> 
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
> 
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
> 
> NB: I manually carved them out of a diff without testing them.

That would be
,
which neither I tested. Testing should first be done for gcc, g++, gcj,
gobjc, gobjc++, gccgo (although I've not managed to use shared libraries
with latest releases, but used to be able to) and gfortran. If someone
wants to test these first to see if it works and then later on do an
archive rebuild, that would also be appreciated.

At that point I could then at least switch the current implementation
so that we can just enable the "pie" feature per package regardless of
it building prorgrams or shared libraries. Enabling it by default
globally would require the usual process described in the dpkg FAQ.

Thanks,
Guillem

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi,

2016-08-21 8:22 GMT+02:00 Niels Thykier :
> Kurt Roeckx:
>> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>>also apply to this port? [0]
>>
>> If -fPIE is the default will -fPIC override it?
>>
>> It will also default to tell the linker to use -pie, but then
>> don't do it when you want to create a shared library?
>>
>
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.
>
> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).
>
> Regardless, it seems to "just work(TM)" if you pass the proper flags
> when compiling your SOs.
>
>>>From what I understand, depending on what the .o file is going to
>> be used for you want different things:
>> - shared library: -fPIC
>> - executable: -fPIC or -fPIE both work, but prefer -fPIE
>> - static library: Same as executables
>>
>> For static libraries we now have a policy to not use -fPIC,
>> should that then get replaced by using -fPIE?
>>
>>
>>
>> Kurt
>>
>
> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all
arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.

My assumption was that this set of architectures need the least amount of
additional work since they are tested already in Ubuntu, but I would be happy
if more ports would opt in for PIE.

I plan filing wishlist bugs against dpkg and gcc with the patches
after I rebuilt a
few packages with the defaults.

Cheers,
Balint

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/


>
> Thanks,
> ~Niels
>
> [1] Example spec files for this case seems to be something like:
>
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
>
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
>
> NB: I manually carved them out of a diff without testing them.
>

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Kurt Roeckx:
> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>also apply to this port? [0]
> 
> If -fPIE is the default will -fPIC override it?
> 
> It will also default to tell the linker to use -pie, but then
> don't do it when you want to create a shared library?
> 

I believe so.  At least, Ubuntu made PIE default in their compiler
without having to change all SO packages to still build.

Admittedly, it could also be that GCC uses some built "compiler spec"
files for this case (a la an implicit "-specs=$FILE"), which are similar
to those Redhat uses for this purposes (see [1] for an example of such
files).

Regardless, it seems to "just work(TM)" if you pass the proper flags
when compiling your SOs.

>>From what I understand, depending on what the .o file is going to
> be used for you want different things:
> - shared library: -fPIC
> - executable: -fPIC or -fPIE both work, but prefer -fPIE
> - static library: Same as executables
> 
> For static libraries we now have a policy to not use -fPIC,
> should that then get replaced by using -fPIE?
> 
> 
> 
> Kurt
> 

Honestly, I had not thought about that.  From the looks of it, de facto
we will end up with -fPIE being the default for static libraries as well.
  I would be supporting that change on the assumption that it requires
less work from individual maintainers (and presumably has no notable
downsides in the final result).

Thanks,
~Niels

[1] Example spec files for this case seems to be something like:

pie-compile.specs
"""
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
"""

pie-link.specs:
"""
*self_spec:
+ %{!shared:%{!r:-pie}}
"""

NB: I manually carved them out of a diff without testing them.

Re: Porter roll call for Debian Stretch

[Kurt Roeckx]

On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>also apply to this port? [0]

If -fPIE is the default will -fPIC override it?

It will also default to tell the linker to use -pie, but then
don't do it when you want to create a shared library?

>From what I understand, depending on what the .o file is going to
be used for you want different things:
- shared library: -fPIC
- executable: -fPIC or -fPIE both work, but prefer -fPIE
- static library: Same as executables

For static libraries we now have a policy to not use -fPIC,
should that then get replaced by using -fPIE?



Kurt

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Martin Michlmayr:
> * ni...@thykier.net  [2016-08-17 22:05]:
>> 2020), please respond with a signed email containing the following
>> before Friday, the 9th of September:
> 
> Can you please specify where to respond to?  I don't think dozens of
> emails to -ports and -devel make any sense.
> 

Ah, sorry I had indeed forgotten to set Reply-To. :)

> Maybe debian-release with CC debian- or to you personally and
> you'll collect the info?
> 

Please send the replies to debian-release. :)

Thanks,
~Niels

Re: Porter roll call for Debian Stretch

[Martin Michlmayr]

* ni...@thykier.net  [2016-08-17 22:05]:
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:

Can you please specify where to respond to?  I don't think dozens of
emails to -ports and -devel make any sense.

Maybe debian-release with CC debian- or to you personally and
you'll collect the info?

-- 
Martin Michlmayr
http://www.cyrius.com/