lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 19 Oct 2010 17:04:37 +0200
From:	Andi Kleen <ak@...ux.intel.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Amerigo Wang <amwang@...hat.com>, linux-kernel@...r.kernel.org,
	Randy Dunlap <rdunlap@...otime.net>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Len Brown <len.brown@...el.com>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	Eric Paris <eparis@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Eric Dumazet <eric.dumazet@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Andy Shevchenko <ext-andriy.shevchenko@...ia.com>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/2] sysctl: remove sysctl syscall


> At the time the deprecation was written we nearly we were in the late
> rc's before anything that cared in practice. glibc has stopped even
> providing a sys_sysctl wrapper now.

What matters are old glibc installations, not new ones.

>> I think it's ok to remove the full tables, but keeping
>> a wrapper just for the functionality glibc use(s/d) is still a good
>> idea.
> I think the only problem should be the arm glibc.  I don't know if
> it's iopl implementation ever got weened off of this.  I tried
> but I didn't have good test machine and submitting patches to
> glibc is much more of a pain than kernel patches.


Eric, I think you have the wrong approach here: it doesn't matter what 
new glibc does,
but what any old glibcs do. If any old one uses it we cannot simply 
remove it.

> To my knowledge there has never been a version of x86 glibc that
> had problems if sys_sysctl returns -ENOSYS, and glibc proper removed
> even that dependency almost as soon as sys_sysctl was deprecated.
>

AFAIK older glibc didn't use some functionality in the kernel if they 
couldn't
figure out the right kernel version. And they were using sysctl for this.



> Last time we discussed this (when I added the compatibility wrapper)
> I couldn't even find a version of glibc that used sysctl, and I could
> not find a distribution old enough that still had a version of glibc
> that used sysctl on x86.

When I did my really old work for sysctl_binary() I ran into this problem.
All glibc binaries on my distribution back then used sysctl.

> We warn on every sys_sysctl value now even the glibc uses and perhaps I
> am blind but I haven't seen any bug reports.  So we should be safe
> turning this off.
>

I don't so. I don't think we can that easily break compatibility, sorry.
Binary compatibility is something very important for Linux.

Anyways I'm fine with removing the bulk of the tables, but not the compat
table for the one glibc uses.

I think the code could be a lot simplified and just provide support
for the single kernel version sysctl though (I had a patch to do that
back then)

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ