On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote:
>
> This system call has been deprecated almost since it was introduced, and
> in a survey of the linux distributions I can no longer find any of them
> that enable CONFIG_SYSCTL_SYSCALL. The only indication that I can find
> that anyone might care is that a few of the defconfigs in the kernel
> enable CONFIG_SYSCTL_SYSCALL. However this appears in only 31 of 414
> defconfigs in the kernel, so I suspect this symbols presence is simply
> because it is harmless to include rather than because it is necessary.
>
> As there appear to be no users of the sysctl system call, remove the
> code. As this removes one of the few uses of the internal kernel mount
> of proc I hope this allows for even more simplifications of the proc
> filesystem.
I'm for it. :) I tripped over this being deprecated over a decade ago. :P
I think you can actually take this further and remove (or at least
empty) the uapi/linux/sysctl.h file too.
--
Kees Cook
Kees Cook <[email protected]> writes:
> On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote:
>>
>> This system call has been deprecated almost since it was introduced, and
>> in a survey of the linux distributions I can no longer find any of them
>> that enable CONFIG_SYSCTL_SYSCALL. The only indication that I can find
>> that anyone might care is that a few of the defconfigs in the kernel
>> enable CONFIG_SYSCTL_SYSCALL. However this appears in only 31 of 414
>> defconfigs in the kernel, so I suspect this symbols presence is simply
>> because it is harmless to include rather than because it is necessary.
>>
>> As there appear to be no users of the sysctl system call, remove the
>> code. As this removes one of the few uses of the internal kernel mount
>> of proc I hope this allows for even more simplifications of the proc
>> filesystem.
>
> I'm for it. :) I tripped over this being deprecated over a decade ago. :P
>
> I think you can actually take this further and remove (or at least
> empty) the uapi/linux/sysctl.h file too.
I copied everyone who had put this into a defconfig and I will wait a
little more to see if anyone screams. I think it is a safe guess that
several of the affected configurations are dead (or at least
unmaintained) as I received 17 bounces when copying everyone.
I would make it a followup that removes uapi/linux/sysctl.h. I don't
see anything in it that isn't about the sysctl system call. I will keep
it a separate patch as I can imagine something silly that needs the
header file to compile. A separate patch would make a revert easier
if we find something like that.
Eric
+Kostya (code owner for LLVM sanitizer_common) as FYI
On Wed, Oct 2, 2019 at 12:54 AM Eric W. Biederman <[email protected]> wrote:
> Kees Cook <[email protected]> writes:
> > On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote:
[...]
> > I think you can actually take this further and remove (or at least
> > empty) the uapi/linux/sysctl.h file too.
[...]
> I would make it a followup that removes uapi/linux/sysctl.h. I don't
> see anything in it that isn't about the sysctl system call. I will keep
> it a separate patch as I can imagine something silly that needs the
> header file to compile. A separate patch would make a revert easier
> if we find something like that.
Unfortunately, I think that header (or at least parts of it) has to
stay around for now:
Looking through the search results for linux/sysctl.h (ignoring
glibc's sys/sysctl.h, which pulls in linux/sysctl.h, because almost
all of those hits are conditional includes for BSD systems) on
codesearch.debian.net, I noticed that e.g. the ASAN code that GCC and
LLVM use pulls in linux/sysctl.h and uses things from it:
https://github.com/llvm-mirror/compiler-rt/blob/124fd5d9aff57cf47bf077df81ad939b289acc6e/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp#L1063
And indeed, after replacing /usr/include/linux/sysctl.h with an empty
file, a build of LLVM's runtime library component (compiler-rt) (git
HEAD version) falls over with error spew about __sysctl_args:
====================
$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_PROJECTS='clang;compiler-rt' -DCMAKE_C_COMPILER=clang-7
-DCMAKE_CXX_COMPILER=clang++-7 -DLLVM_TARGETS_TO_BUILD="X86"
-DLLVM_USE_LINKER=lld-7 -DBUILD_SHARED_LIBS=Off ../llvm
[...]
$ ninja -j64
FAILED: projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.i386.dir/sanitizer_platform_limits_posix.cpp.o
[...]
[...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:1063:17:
error: use of undeclared identifier '__sysctl_args'
CHECK_TYPE_SIZE(__sysctl_args);
^
[...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:1064:23:
error: use of undeclared identifier '__sysctl_args'
CHECK_SIZE_AND_OFFSET(__sysctl_args, name);
^
[...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:1064:1:
error: expected expression
CHECK_SIZE_AND_OFFSET(__sysctl_args, name);
^
[...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h:1438:34:
note: expanded from macro 'CHECK_SIZE_AND_OFFSET'
sizeof(((CLASS *)NULL)->MEMBER)); \
^
[...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:1064:23:
error: unknown type name '__sysctl_args'
CHECK_SIZE_AND_OFFSET(__sysctl_args, name);
^
====================
On Wed, Oct 2, 2019 at 12:54 AM Eric W. Biederman <[email protected]> wrote:
> Kees Cook <[email protected]> writes:
> > On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote:
> >
> > I think you can actually take this further and remove (or at least
> > empty) the uapi/linux/sysctl.h file too.
>
> I copied everyone who had put this into a defconfig and I will wait a
> little more to see if anyone screams. I think it is a safe guess that
> several of the affected configurations are dead (or at least
> unmaintained) as I received 17 bounces when copying everyone.
Looking at the arm defconfigs:
> arch/arm/configs/axm55xx_defconfig:CONFIG_SYSCTL_SYSCALL=y
No notable work on this platform since it got sold to Intel in 2014.
I think they still use it but not with mainline kernels that lack support
for most drivers and the later chips.
> arch/arm/configs/keystone_defconfig:CONFIG_SYSCTL_SYSCALL=y
Not that old either, but this hardware is mostly obsoleted by newer variants
that we support with the arm64 defconfig.
> arch/arm/configs/lpc32xx_defconfig:CONFIG_SYSCTL_SYSCALL=y
> arch/arm/configs/moxart_defconfig:CONFIG_SYSCTL_SYSCALL=y
Ancient hardware, but still in active use. These tend to have very little
RAM, but they both enable CONFIG_PROC_FS.
> arch/arm/configs/qcom_defconfig:CONFIG_SYSCTL_SYSCALL=y
> arch/arm/configs/zx_defconfig:CONFIG_SYSCTL_SYSCALL=y
These are for older Qualcomm and LG chips that tend to be used
with Android rather than the defconfig here. Maybe double-check
if the official android-common tree enables SYSCTL_SYSCALL.
Arnd
Arnd Bergmann <[email protected]> writes:
> On Wed, Oct 2, 2019 at 12:54 AM Eric W. Biederman <[email protected]> wrote:
>> Kees Cook <[email protected]> writes:
>> > On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote:
>> >
>> > I think you can actually take this further and remove (or at least
>> > empty) the uapi/linux/sysctl.h file too.
>>
>> I copied everyone who had put this into a defconfig and I will wait a
>> little more to see if anyone screams. I think it is a safe guess that
>> several of the affected configurations are dead (or at least
>> unmaintained) as I received 17 bounces when copying everyone.
>
> Looking at the arm defconfigs:
>
>> arch/arm/configs/axm55xx_defconfig:CONFIG_SYSCTL_SYSCALL=y
>
> No notable work on this platform since it got sold to Intel in 2014.
> I think they still use it but not with mainline kernels that lack support
> for most drivers and the later chips.
>
>> arch/arm/configs/keystone_defconfig:CONFIG_SYSCTL_SYSCALL=y
>
> Not that old either, but this hardware is mostly obsoleted by newer variants
> that we support with the arm64 defconfig.
>
>> arch/arm/configs/lpc32xx_defconfig:CONFIG_SYSCTL_SYSCALL=y
>> arch/arm/configs/moxart_defconfig:CONFIG_SYSCTL_SYSCALL=y
>
> Ancient hardware, but still in active use. These tend to have very little
> RAM, but they both enable CONFIG_PROC_FS.
>
>> arch/arm/configs/qcom_defconfig:CONFIG_SYSCTL_SYSCALL=y
>> arch/arm/configs/zx_defconfig:CONFIG_SYSCTL_SYSCALL=y
>
> These are for older Qualcomm and LG chips that tend to be used
> with Android rather than the defconfig here. Maybe double-check
> if the official android-common tree enables SYSCTL_SYSCALL.
I just looked quickly at:
https://android.googlesource.com/kernel/configs/
I don't see the string SYSCTL mentioned anywhere. Much less
SYSCTL_SYSCALL.
Eric
Arnd Bergmann <[email protected]> writes:
> On Wed, Oct 2, 2019 at 12:54 AM Eric W. Biederman <[email protected]> wrote:
>> arch/arm/configs/lpc32xx_defconfig:CONFIG_SYSCTL_SYSCALL=y
>> arch/arm/configs/moxart_defconfig:CONFIG_SYSCTL_SYSCALL=y
>
> Ancient hardware, but still in active use. These tend to have very little
> RAM, but they both enable CONFIG_PROC_FS.
You actually have to enable CONFIG_PROC_FS to enable
CONFIG_SYSCTL_SYSCALL at this point. CONFIG_SYSCTL_SYSCALL is just an
emulation of the old interface built on top of /proc.
Thank you for the feedback.
Eric
On 02.10.19 00:53, Eric W. Biederman wrote:
> Kees Cook <[email protected]> writes:
>>> As there appear to be no users of the sysctl system call, remove the
>>> code....>...
> I copied everyone who had put this into a defconfig and I will wait a
> little more to see if anyone screams. I think it is a safe guess that
> several of the affected configurations are dead (or at least
> unmaintained) as I received 17 bounces when copying everyone.
arch/parisc/configs/c8000_defconfig | 1 -
arch/parisc/configs/generic-32bit_defconfig | 1 -
I'm not aware that we require the sysctl syscall somewhere on parisc,
so I think it's safe to remove the code.
Helge
Is anyone else getting a very incomplete set of messages in this
thread?
These changes likely matter to glibc, and I've yet to see the actual
patch. Would someone please forward it to me?
The original message didn't make it into the lore.kernel.org archives
(the cross-post to linux-kernel should have taken care of that).
On Thu, Oct 03, 2019 at 08:56:19AM +0200, Florian Weimer wrote:
> Is anyone else getting a very incomplete set of messages in this
> thread?
>
> These changes likely matter to glibc, and I've yet to see the actual
> patch. Would someone please forward it to me?
>
> The original message didn't make it into the lore.kernel.org archives
> (the cross-post to linux-kernel should have taken care of that).
Yeah, I didn't get it either and the repost too weirdly enough.
Christian
* Christian Brauner:
> On Thu, Oct 03, 2019 at 08:56:19AM +0200, Florian Weimer wrote:
>> Is anyone else getting a very incomplete set of messages in this
>> thread?
>>
>> These changes likely matter to glibc, and I've yet to see the actual
>> patch. Would someone please forward it to me?
>>
>> The original message didn't make it into the lore.kernel.org archives
>> (the cross-post to linux-kernel should have taken care of that).
>
> Yeah, I didn't get it either and the repost too weirdly enough.
I got curious and tried to repost the repost to vger.kernel.org (in
the hope to bypass any SMTP callout verifications that may still be
failing for Eric), and got this:
2019-10-04 07:09:29 1iGHiT-00007b-Na <= [email protected] H=(deneb.enyo.de) [172.17.203.2] P=esmtps X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=no S=72580 [email protected]
2019-10-04 07:09:37 1iGHiT-00007b-Na => [email protected] R=dnslookup T=remote_smtp_ext H=vger.kernel.org [209.132.180.67] C="250 2.7.1 Looks like Linux source DIFF email.. BF:<S 1>; S1728766AbfJDHJg"
2019-10-04 07:09:37 1iGHiT-00007b-Na -> [email protected] R=dnslookup T=remote_smtp_ext H=vger.kernel.org [209.132.180.67] C="250 2.7.1 Looks like Linux source DIFF email.. BF:<S 1>; S1728766AbfJDHJg"
2019-10-04 07:09:37 1iGHiT-00007b-Na -> [email protected] R=dnslookup T=remote_smtp_ext H=vger.kernel.org [209.132.180.67] C="250 2.7.1 Looks like Linux source DIFF email.. BF:<S 1>; S1728766AbfJDHJg"
2019-10-04 07:09:37 1iGHiT-00007b-Na Completed
But nothing came back. Timestamps are UTC.
Dave, could please have a look, assuming that you are still involved
with vger operations?