linux-kernel - Re: [RFC v2 1/2] kernel/sysctl: support setting sysctl parameters from kernel command line

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: <20200326065829.GC27965@dhcp22.suse.cz>
Date:   Thu, 26 Mar 2020 07:58:29 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Vlastimil Babka <vbabka@...e.cz>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Iurii Zaikin <yzaikin@...gle.com>,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        linux-mm@...ck.org, Ivan Teterevkov <ivan.teterevkov@...anix.com>,
        David Rientjes <rientjes@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        "Guilherme G . Piccoli" <gpiccoli@...onical.com>
Subject: Re: [RFC v2 1/2] kernel/sysctl: support setting sysctl parameters
 from kernel command line

On Wed 25-03-20 17:20:40, Eric W. Biederman wrote:
> Vlastimil Babka <vbabka@...e.cz> writes:
[...]
> > +	if (strncmp(param, "sysctl.", sizeof("sysctl.") - 1))
> > +		return 0;
> 
> Is there any way we can use a slash separated path.  I know
> in practice there are not any sysctl names that don't have
> a '.' in them but why should we artifically limit ourselves?

Because this is the normal userspace interface? Why should it be any
different from calling sysctl?
[...]

> Further it will be faster to lookup the sysctls using the code from
> proc_sysctl.c as it constructs an rbtree of all of the entries in
> a directory.  The code might as well take advantage of that for large
> directories.

Sounds like a good fit for a follow up patch to me. Let's make this
as simple as possible for the initial version. But up to Vlastimil of
course.

[...]

> Hmm.  There is a big gotcha in here and I think it should be mentioned.
> This code only works because no one has done set_fs(KERNEL_DS).  Which
> means this only works with strings that are kernel addresses essentially
> by mistake.  A big fat comment documenting why it is safe to pass in
> kernel addresses to a function that takes a "char __user*" pointer
> would be very good.

Agreed

-- 
Michal Hocko
SUSE Labs