On Thu, Jun 11, 2020 at 06:43:00AM -0500, Eric W. Biederman wrote:

Xiaoming Ni [off-list ref] writes:

quoted

Since the commit 61a47c1ad3a4dc ("sysctl: Remove the sysctl system call"),
sys_sysctl is actually unavailable: any input can only return an error.

We have been warning about people using the sysctl system call for years
and believe there are no more users.  Even if there are users of this
interface if they have not complained or fixed their code by now they
probably are not going to, so there is no point in warning them any
longer.

So completely remove sys_sysctl on all architectures.

quoted

Signed-off-by: Xiaoming Ni <redacted>

changes in v2:
  According to Kees Cook's suggestion, completely remove sys_sysctl on all arch
  According to Eric W. Biederman's suggestion, update the commit log

V1: https://lore.kernel.org/lkml/1591683605-8585-1-git-send-email-nixiaoming@huawei.com/ (local)
  Delete the code of sys_sysctl and return -ENOSYS directly at the function entry
---
 include/uapi/linux/sysctl.h                        |  15 --

[snip]

quoted

diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 27c1ed2..84b44c3 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h

@@ -27,21 +27,6 @@
 #include <linux/types.h>
 #include <linux/compiler.h>
 
-#define CTL_MAXNAME 10		/* how many path components do we allow in a
-				   call to sysctl?   In other words, what is
-				   the largest acceptable value for the nlen
-				   member of a struct __sysctl_args to have? */
-
-struct __sysctl_args {
-	int __user *name;
-	int nlen;
-	void __user *oldval;
-	size_t __user *oldlenp;
-	void __user *newval;
-	size_t newlen;
-	unsigned long __unused[4];
-};
-
 /* Define sysctl names first */
 
 /* Top-level names: */

[snip]

The uapi header change does not make sense.  The entire point of the
header is to allow userspace programs to be able to call sys_sysctl.
It either needs to all stay or all go.

As the concern with the uapi header is about userspace programs being
able to compile please leave the header for now.

We should leave auditing userspace and seeing if userspace code will
still compile if we remove this header for a separate patch.  The
concerns and justifications for the uapi header are completely different
then for the removing the sys_sysctl implementation.

Otherwise
Acked-by: "Eric W. Biederman" <redacted>

The UAPI header should be kept because it's defining an API not just
for the kernel the headers are supplied with, but for all past
kernels. In particular programs needing a failsafe CSPRNG source that
works on old kernels may (do) use this as a fallback only if modern
syscalls are missing. Removing the syscall is no problem since it
won't be used, but if you remove the types/macros from the UAPI
headers, they'll have to copy that into their own sources.

Rich