Hi!
On Tue, 2023-07-04 at 13:12:48 +0300, Adrian Bunk wrote:
> On Tue, Jul 04, 2023 at 09:23:43AM +0200, Guillem Jover wrote:
> > On Sun, 2023-07-02 at 00:02:46 +0300, Adrian Bunk wrote:
> > > There are some problems with this:
> > >
> > > 1. PIE should either be default or not be used
> > >
> > > I suspect x32 might be able to default to PIE without problems
> > > (there might just not be enough interest left to change the default).
> > >
> > > On alpha the toolchain has already become quite brittle
> > > with frequent issues like (reproducible) linker segfaults,
> > > any variations that affects the toolchain are bad.
> > >
> > > It is for the port maintainers to decide whether or not PIE
> > > is considered stable on a port, and accordingly either make
> > > it default (which also avoids the other issues below) or not.
> > >
> > > It is clear that a non-PIE architecture would no longer be
> > > considered suitable as release architecture.
> >
> > In general the way this is handled in dpkg, is that if the flags
> > supposedly work on that arch they are allowed, but if they are not
> > supported or are broken then they are masked.
I recalled this report before the 1.22.1 release, but didn't feel it
appropriate to push a last minute change for it, before giving some
advance notice, and because I was also expecting some word from the
relevant arch porters.
I guess I could do it the other way, and given this is apparently
causing issues as reported by Adrian, and as seen recently from
the referenced bug report which might require patching a specific
package to disable PIE there, I'm inclined to completely mask PIE
in dpkg-buildflags for alpha and ia64 in around a couple of weeks,
if I don't hear anything.
> > > Please drop pie-{compile,link}.spec, on the architectures
> > > where it has any effect it is doing more harm than good.
> >
> > For example hppa has pie masked for build flags. If the porters for
> > alpha and/or ia64 consider that they should also get pie masked for
> > those arches, I'm fine doing the changes. Although that means on those
> > ports it will not be possible to enable pie at all, even if asked for
> > explicitly, as in «hardening=+pie».
>
> Semi-PIE non-release architectures shouldn't exist, PIE on an·
> architecture should be a binary option decided by the porters
> for this architecture.
>
> If there are any porters left on an architecture and they consider PIE·
> stable, they can always ask the gcc maintainer to change the default.[1]
>
> >...
> > > The lowest effort fix would be to patch debian/rules of affected
> > > packages to disable hardening=+pie on affected architectures,
> > > but that would still be spending time on working around a problem
> > > that shouldn't exist.
> >
> > Yeah, that does not look like the right thing to be spending time on.
> >...
>
> As long as we have at least one semi-PIE architecture, this is the only·
> realistic option for porters. If the porters for alpha and/or ia64 want·
> to have pie masked, such changes will still be required for x32.
If PIE (via specs files) appears to work on x32, and changing the
defaults in gcc is too much to bother, I think leaving it as is looks
fine by me. But if this is causing problems as well and the x32 porters
(if there's any remaining :), want to mask it alongside the other ports,
let me know and I can also flip the switch for that one.
Thanks,
Guillem
