On Mon, May 18, 2020 at 06:57:15PM -0500, Eric W. Biederman wrote: > Christian Brauner <christian.brauner@xxxxxxxxxx> writes: > > > On Mon, May 18, 2020 at 04:43:20PM +0200, Jann Horn wrote: > >> On Mon, May 18, 2020 at 3:03 PM Christian Brauner > >> <christian.brauner@xxxxxxxxxx> wrote: > >> > Also - gulp (puts on flame proof suit) - may I suggest we check if there > >> > are any distros out there that still set CONFIG_USELIB=y > >> > >> Debian seems to have it enabled on x86... > >> > >> https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/kernelarch-x86/config#L1896 > >> > >> A random Ubuntu 19.10 VM I have here has it enabled, too. > > > > I wonder if there's any program - apart from _ancient_ glibc out there > > that actually use it... > > I looked at uselib in codsearch but the results were quite unspecific > > but I didn't look too close. > > So the thing to do is to have a polite word with people who build Ubuntu > and Debian kernels and get them to disable the kernel .config. Yeah, I think that's a sane thing to do. I filed a bug for Ubuntu to start a discussion. I can't see an obvious reason why not. > > A quick look suggets it is already disabled in RHEL8. It cannot be > disabled in RHEL7. > > Then in a few years we can come back and discuss removing the uselib > system call, base on no distributions having it enabled. > > If it was only libc4 and libc5 that used the uselib system call then it > can probably be removed after enough time. > > We can probably reorganize the code before the point it is clearly safe > to drop support for USELIB to keep it off to the side so USELIB does not > have any ongoing mainteance costs. > > For this patchset I think we need to assume uselib will need to be > maintained for a bit longer. Yeah, agreed. It doesn't matter as long as we have a plan for the future to remove it. I don't think keeping this cruft around forever should be the only outlook. Christian
