linux-kernel - Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support

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]

Message-ID: <m1tyx49y44.fsf@fess.ebiederm.org>
Date:	Sun, 08 Nov 2009 19:27:07 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Russell King <rmk+lkml@....linux.org.uk>,
	linux-kernel@...r.kernel.org, Leo Chen <leochen@...adcom.com>
Subject: Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support

Arjan van de Ven <arjan@...radead.org> writes:

> On Sun, 08 Nov 2009 15:05:05 -0800
> ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
>> >
>> > The practical difference is that /proc support now must be compiled
>> > in to support sys_sysctl.
>> 
>> But thanks for the reminder that I need to go into glibc and fix this
>> before we disable the sys_sysctl emulation by default.
>
> how are you dealing with existing glibcs ? Or with static linked
> binaries? or.. or ..
>
> breaking a heavily used ABI like this is not going to be pretty
> or even sane, no matter which way you hate the current one.

sysctl_binary.c has all of the code to continue to provide the
existing ABI.

sys_sysctl is not heavily used at all, and this is the responsible
removal of a practically unused ABI.  Last I check (and this was
before I shouted to the world that sys_sysctl is going away) I could
count on one hand all of the users of sys_sysctl.

/proc/sys will definitely continue to exist.

I just took a look and the use in linux threads that I don't warn
about is used by glibc-2.8 but not by glibc-2.10.  glibc-2.11 has just
been released. so by next year when the removal is scheduled we are
looking at multiple releases of glibc that don't use sys_sysctl.  So I
expect shortly I can warn about all uses of sys_sysctl without anyone
seeing a warning.

The one unfixed case I know about is fixing ioperm on arm, in the glibc
ports tree, and that will need to happen before sys_sysctl is disabled
by default.  Which is all I intend to do when we reach that point in
feature removal schedule now that I have refactored the code so that
sys_sysctl no longer imposes a maintenance burden on the sane sysctl
users.

I don't hate sysctl, in fact for global tuneables I would argue for
all it's faults sysctl it is one of the better interfaces we have.  I
just figure the implementation needs to be optimized for the way
sysctl is used today, the via /proc/sys.

Eric
--
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/