[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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-mips@lists.debian.org, lintian@packages.debian.org, jrtc27@debian.org
> User: debian-mips@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
> <https://udd.debian.org/lintian/?packages=samba>.
> 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.


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

Reply to: