Re: Really enable -fstack-clash-protection on armhf/armel?
Hi,
Short introduction: I work at Canonical in the Foundations team and made
changes in gnutls which is one of the packages that first
encountered/caused issues which then started blocking various migrations
and changes.
On Fri, Nov 24, 2023, Matthias Klose wrote:
> On 24.11.23 07:19, Emanuele Rocca wrote:
> > Hello!
> >
> > On 2023-11-24 01:34, Guillem Jover wrote:
> > > According to https://bugs.debian.org/918914#73 there were no pending
> > > toolchain issues related to this.
> >
> > That is correct. The GCC maintainers at Arm confirm that
> > stack-clash-protection is supported on 32 bit too.
>
> yes, but it's a different implementation, that apparently breaks a few more
> things than on the other architectures where it is enabled.
> >
> > In case there are any bugs, which is of course possible, please file
> > them and add debian-arm@ to X-Debbugs-CC.
>
> No, I will not do that. Sorry, but the task of the porters it NOT to put
> this kind of work on the shoulders on others, but to do this analysis
> themself. You seem to rely on every other package maintainer to figure out
> these issues on their own. Please don't do that.
>
> Debian is the first distro to turn this on on armhf, but didn't do any
> checks or test rebuilds before turning this on.
>
> > So far I'm only aware of an issue with plplot, which turned out to be an
> > actual bug in the software that stack-clash-protection helped uncover:
> > https://bugs.debian.org/1055228#24
>
> I filed now
> https://bugs.launchpad.net/ubuntu/+source/libselinux/+bug/2044506
> to collect some information what Ubuntu apparently hit.
Thanks. I put some details on
https://code.launchpad.net/~adrien-n/ubuntu/+source/dpkg/+git/dpkg/+merge/456181
and I'll expand the information on the bug but I need a couple hours
first. I expected the topic to be shorter somehow (it was late in the
day :) ).
> A major problem will be valgrind stopping to work, causing issues in the
> test suites of other packages.
>
> Also after rebuilding libxml2, libarchive, gnutls28, libselinux without this
> flag on armhf, issues go away again. I'm not directly working on these, so
> can't give more information.
I'm not opposed to investigating the issues but the number of failures
we'll get is still unknown, and their source and whether it would
actually be due to the use of valgrind aren't clear. In any case, the
failure under valgrind is 100% unexploitable. I want to look at that
plplot bug in order to understand how this helped find an actual bug
because what I've seen so far doesn't lend itself to quick analysis.
What I'm not convinced is that packages should be uploaded in that
state. As far as I understand, it's possible to work on the libraries of
a single package at a time and a test rebuild followed by an (emulated)
autopkgtest should be enough; iterating maybe wouldn't be incredibly
fast but still probably much faster than iterating through the archive.
Moreover a local build is probably needed anyway because AFAICT there's
nothing to learn from the current test logs.
I'm not here to tell how to run Debian and it's probably worth noting
that we're still early in the current debian cycle while we're quite far
in the ubuntu cycle for an LTS release (plus holidays season). This
might lead to different solutions but in any case, the change and the
breadth and depth of its consequences were a surprise; this is recent
yet the problematic packages were really quickly piling on.
Reflecting a bit more on this: would the issues raised be always
similar? I mean, if we expect the same kind of issues in most packages
and the same solutions, we should make a guide for maintainers so they
can address this quickly. And if it's likely different every time, we
need to think about the maintainers' time and availability.
--
Adrien
Reply to: