Bug#1022787: Bug#1025436: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Axel Beckert]

Hi,

Axel Beckert wrote:
> Aurelien Jarno wrote:
> > Given we got no decision from the MIPS porters before the toolchain
> > freeze, we'll have to live with the executable stack on mips*el for
> > bookworm.
> > 
> > Therefore I believe it's a good idea to disable that tag on mips*el on
> > the lintian side.
> 
> Ok, thanks. Will look into it now.

Fixed in git with this commit, referring to #1025436 and #1022787:

https://salsa.debian.org/lintian/lintian/-/commit/80ec3ca960e73a0717719d1329331f86d387c4ae

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1022787: Bug#1025436: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Axel Beckert]

Hi Aurelien,

your reply is just in time! Because about five minutes ago, I started
to continue working on Lintian for this evening. The plan: Making the
long overdue upload as I fixed the last part of arm64 autopkgtest
failures last night. :-)

Aurelien Jarno wrote:
> Given we got no decision from the MIPS porters before the toolchain
> freeze, we'll have to live with the executable stack on mips*el for
> bookworm.
> 
> Therefore I believe it's a good idea to disable that tag on mips*el on
> the lintian side.

Ok, thanks. Will look into it now.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Aurelien Jarno]

Hi,

On 2023-01-16 13:26, Guillem Jover wrote:
> Hi!
> 
> On Mon, 2023-01-16 at 12:47:23 +0100, Axel Beckert wrote:
> > Aurelien Jarno wrote:
> > > On 2022-10-26 22:09, Aurelien Jarno wrote:
> > > > Note that the other official architecture still have a kernel
> > > > compatibility set to 3.2, so that will make a difference between
> > > > architectures. There are discussions to increase it upstream, but this
> > > > won't happened for bookworm. 
> > > > 
> > > > On 2022-10-25 21:07, Simon McVittie wrote:
> > > > > Or, if the mips porters consider this backwards compatibility to be
> > > > > more important than the security hardening of a non-executable stack,
> > > > > then Lintian should stop issuing warnings about the executable stack 
> > > > > on
> > > > > mips*el to improve its signal/noise ratio.
> > > > 
> > > > At this stage there is nothing that can be done on the glibc side, the
> > > > decision has to be taken by the mips porters.
> > > 
> > > We are getting very close to the toolchain freeze. Any decision about
> > > that?
> > 
> > JFYI: There is the request to disable this tag completely on MIPS
> > architectures in https://bugs.debian.org/1025436
> > 
> > Now I wonder if this would actually help or worsen the situation for
> > the glibc maintainers.
> > 
> > Guillem: You wrote something about "bullseye" in #1025436. I think you
> > meant "bookworm" instead. Am I right?
> 
> Indeed, sorry, I was going by Aurelien's comment, but botched the
> release name. :) But in any case, I'll defer to whatever take Aurelien
> or other glibc maintainers have on this.

Given we got no decision from the MIPS porters before the toolchain
freeze, we'll have to live with the executable stack on mips*el for
bookworm.

Therefore I believe it's a good idea to disable that tag on mips*el on
the lintian side.

Cheers
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Guillem Jover]

Hi!

On Mon, 2023-01-16 at 12:47:23 +0100, Axel Beckert wrote:
> Aurelien Jarno wrote:
> > On 2022-10-26 22:09, Aurelien Jarno wrote:
> > > Note that the other official architecture still have a kernel
> > > compatibility set to 3.2, so that will make a difference between
> > > architectures. There are discussions to increase it upstream, but this
> > > won't happened for bookworm. 
> > > 
> > > On 2022-10-25 21:07, Simon McVittie wrote:
> > > > Or, if the mips porters consider this backwards compatibility to be
> > > > more important than the security hardening of a non-executable stack,
> > > > then Lintian should stop issuing warnings about the executable stack on
> > > > mips*el to improve its signal/noise ratio.
> > > 
> > > At this stage there is nothing that can be done on the glibc side, the
> > > decision has to be taken by the mips porters.
> > 
> > We are getting very close to the toolchain freeze. Any decision about
> > that?
> 
> JFYI: There is the request to disable this tag completely on MIPS
> architectures in https://bugs.debian.org/1025436
> 
> Now I wonder if this would actually help or worsen the situation for
> the glibc maintainers.
> 
> Guillem: You wrote something about "bullseye" in #1025436. I think you
> meant "bookworm" instead. Am I right?

Indeed, sorry, I was going by Aurelien's comment, but botched the
release name. :) But in any case, I'll defer to whatever take Aurelien
or other glibc maintainers have on this.

Thanks,
Guillem

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Axel Beckert]

Hi,

writing this with my Lintian maintainer hat on. Nearly full quote due
to Cc'ing another bug report and bug reporter:

Aurelien Jarno wrote:
> On 2022-10-26 22:09, Aurelien Jarno wrote:
> > control: tag -1 + moreinfo
> > 
> > On 2022-10-25 21:07, Simon McVittie wrote:
> > > Package: libc6-dev
> > > Version: 2.35-4
> > > Severity: normal
> > > X-Debbugs-Cc: debian-m...@lists.debian.org, lint...@packages.debian.org, 
> > > jrt...@debian.org
> > > User: debian-m...@lists.debian.org
> > > Usertags: mips mipsel
> > > 
> > > All mips*el executables and libraries appear to have an executable stack,
> > > resulting in very large numbers of Lintian warnings, particularly for
> > > packages with many small ELF objects like
> > > .
> > > 
> > > Jessica Clarke looked into this and found that this is intentionally done
> > > by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat:
> > > https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143
> > > 
> > > Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably
> > > doesn't need to go that far into backwards compatibility? If the mips
> > > porters agree, then glibc on mips*el should stop forcing an executable
> > > stack, either by increasing the minimal kernel version or by patching
> > > this out. That will provide some security hardening on mips*el.
> > 
> > Note that the other official architecture still have a kernel
> > compatibility set to 3.2, so that will make a difference between
> > architectures. There are discussions to increase it upstream, but this
> > won't happened for bookworm. 
> > 
> > > Or, if the mips porters consider this backwards compatibility to be
> > > more important than the security hardening of a non-executable stack,
> > > then Lintian should stop issuing warnings about the executable stack on
> > > mips*el to improve its signal/noise ratio.
> > 
> > At this stage there is nothing that can be done on the glibc side, the
> > decision has to be taken by the mips porters.
> 
> We are getting very close to the toolchain freeze. Any decision about
> that?

JFYI: There is the request to disable this tag completely on MIPS
architectures in https://bugs.debian.org/1025436

Now I wonder if this would actually help or worsen the situation for
the glibc maintainers.

Guillem: You wrote something about "bullseye" in #1025436. I think you
meant "bookworm" instead. Am I right?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Aurelien Jarno]

Hi,

On 2022-10-26 22:09, Aurelien Jarno wrote:
> control: tag -1 + moreinfo
> 
> Hi,
> 
> On 2022-10-25 21:07, Simon McVittie wrote:
> > Package: libc6-dev
> > Version: 2.35-4
> > Severity: normal
> > X-Debbugs-Cc: debian-m...@lists.debian.org, lint...@packages.debian.org, 
> > jrt...@debian.org
> > User: debian-m...@lists.debian.org
> > Usertags: mips mipsel
> > 
> > All mips*el executables and libraries appear to have an executable stack,
> > resulting in very large numbers of Lintian warnings, particularly for
> > packages with many small ELF objects like
> > .
> > 
> > Jessica Clarke looked into this and found that this is intentionally done
> > by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat:
> > https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143
> > 
> > Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably
> > doesn't need to go that far into backwards compatibility? If the mips
> > porters agree, then glibc on mips*el should stop forcing an executable
> > stack, either by increasing the minimal kernel version or by patching
> > this out. That will provide some security hardening on mips*el.
> 
> Note that the other official architecture still have a kernel
> compatibility set to 3.2, so that will make a difference between
> architectures. There are discussions to increase it upstream, but this
> won't happened for bookworm. 
> 
> > Or, if the mips porters consider this backwards compatibility to be
> > more important than the security hardening of a non-executable stack,
> > then Lintian should stop issuing warnings about the executable stack on
> > mips*el to improve its signal/noise ratio.
> 
> At this stage there is nothing that can be done on the glibc side, the
> decision has to be taken by the mips porters.

We are getting very close to the toolchain freeze. Any decision about
that?

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Aurelien Jarno]

control: tag -1 + moreinfo

Hi,

On 2022-10-25 21:07, Simon McVittie wrote:
> Package: libc6-dev
> Version: 2.35-4
> Severity: normal
> X-Debbugs-Cc: debian-m...@lists.debian.org, lint...@packages.debian.org, 
> jrt...@debian.org
> User: debian-m...@lists.debian.org
> Usertags: mips mipsel
> 
> All mips*el executables and libraries appear to have an executable stack,
> resulting in very large numbers of Lintian warnings, particularly for
> packages with many small ELF objects like
> .
> 
> Jessica Clarke looked into this and found that this is intentionally done
> by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat:
> https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143
> 
> Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably
> doesn't need to go that far into backwards compatibility? If the mips
> porters agree, then glibc on mips*el should stop forcing an executable
> stack, either by increasing the minimal kernel version or by patching
> this out. That will provide some security hardening on mips*el.

Note that the other official architecture still have a kernel
compatibility set to 3.2, so that will make a difference between
architectures. There are discussions to increase it upstream, but this
won't happened for bookworm. 

> Or, if the mips porters consider this backwards compatibility to be
> more important than the security hardening of a non-executable stack,
> then Lintian should stop issuing warnings about the executable stack on
> mips*el to improve its signal/noise ratio.

At this stage there is nothing that can be done on the glibc side, the
decision has to be taken by the mips porters.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Processed: Re: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Debian Bug Tracking System]

Processing control commands:

> tag -1 + moreinfo
Bug #1022787 [libc6-dev] libc6-dev: Lintian warns that all mips*el executables 
have executable stack
Added tag(s) moreinfo.

-- 
1022787: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022787
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Simon McVittie]

Package: libc6-dev
Version: 2.35-4
Severity: normal
X-Debbugs-Cc: debian-m...@lists.debian.org, lint...@packages.debian.org, 
jrt...@debian.org
User: debian-m...@lists.debian.org
Usertags: mips mipsel

All mips*el executables and libraries appear to have an executable stack,
resulting in very large numbers of Lintian warnings, particularly for
packages with many small ELF objects like
.

Jessica Clarke looked into this and found that this is intentionally done
by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat:
https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143

Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably
doesn't need to go that far into backwards compatibility? If the mips
porters agree, then glibc on mips*el should stop forcing an executable
stack, either by increasing the minimal kernel version or by patching
this out. That will provide some security hardening on mips*el.

Or, if the mips porters consider this backwards compatibility to be
more important than the security hardening of a non-executable stack,
then Lintian should stop issuing warnings about the executable stack on
mips*el to improve its signal/noise ratio.

Thanks,
smcv