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  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]
Date:	Mon, 09 Nov 2009 20:42:47 -0800
From: (Eric W. Biederman)
To:	Arnd Bergmann <>
Cc:	Andi Kleen <>,
	Arjan van de Ven <>,
Subject: Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support

Arnd Bergmann <> 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->
		len = sizeof(current->nsporxy->;
	ret = copy_to_user(buf, current->nsproxy->, len);

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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists