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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1ocnbrnw8.fsf@fess.ebiederm.org>
Date:	Mon, 09 Nov 2009 20:42:47 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support

Arnd Bergmann <arnd@...db.de> writes:

> On Monday 09 November 2009, Andi Kleen wrote:
>> > 
>> > So? Most users of old glibc are also using old kernels, and they
>> 
>> How do you know? At least here it's quite common to use new kernels
>> with old user land.
>
> If by 'here' you mean kernel developers, sure. Other people I'd
> assume typically run whatever comes with the distro, and that
> usually includes both a libc and a kernel.

The question with respect to my patchset. Is the increase in time
a measurable performace regression or is the cost lost in the noise?

Andi do you know of a way to measure this?

Doing a special case for /proc/sys/kernel/version if someone can
measure the overhead seem sane.  But the double maintenance isn't
my idea of fun.

The code involved would need to look something like:

	if (len > sizeof(current->nsporxy->uts_ns.name.version)
		len = sizeof(current->nsporxy->uts_ns.name.version);
	down_read(&uts_sem);
	ret = copy_to_user(buf, current->nsproxy->uts_ns.name.version, len);
	up_read(&uts_sem);

That isn't a particular pretty expression, and it has a much higher chance
of bitrotting than what I have now.

>> > can still use the  config option for the compatibility code.
>> > There wouldn't even be a performance penalty over new glibc with
>> > new kernels which already use procfs.
>> 
>> When he drops the sysctl(2) API completely the old userland will
>> be unhappy.
>
> I did not get the impression that this was the plan. Maybe I missed
> something, but the work that Eric did seemed to be strategic for
> leaving the code around for a really long time without causing any
> maintainance pain that the current code does.
>
> It will be years before we can really remove that code, but distros
> can start disabling it (or making it modular) earlier than that
> when they feel the time has come to stop support for static binaries
> using sysctl (there should really be few of those).

There is always the question if we can get away with it.  I intend to
submit a patch that changes the default to off.  Beyond that I don't
don't know.  I expect folks doing enterprise distro would want to turn
of sys_sysctl because it is a typically buggy.  Why chance bitrot leading
to a security hole?

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/