From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5878EC2BA15 for ; Thu, 2 Apr 2020 20:59:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 267F02064A for ; Thu, 2 Apr 2020 20:59:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 267F02064A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B31908E0008; Thu, 2 Apr 2020 16:59:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE1B18E0007; Thu, 2 Apr 2020 16:59:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1EA88E0008; Thu, 2 Apr 2020 16:59:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0207.hostedemail.com [216.40.44.207]) by kanga.kvack.org (Postfix) with ESMTP id 8A4928E0007 for ; Thu, 2 Apr 2020 16:59:36 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4EAC0180AD811 for ; Thu, 2 Apr 2020 20:59:36 +0000 (UTC) X-FDA: 76664131152.17.floor02_199c9baffe137 X-HE-Tag: floor02_199c9baffe137 X-Filterd-Recvd-Size: 8069 Received: from mail-pj1-f66.google.com (mail-pj1-f66.google.com [209.85.216.66]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 2 Apr 2020 20:59:35 +0000 (UTC) Received: by mail-pj1-f66.google.com with SMTP id ng8so2032409pjb.2 for ; Thu, 02 Apr 2020 13:59:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0E1gU86DMMmY3TlJlUrGFci/4+h2XPiJTo24Taxnmhk=; b=TixFqEQm2uNdk6grBfTCyhi9Oe9gYSLk1Kxbk8HD3nXnmR+aIxAH+0utPSiLy9e+Am t4z1ArpKzu03sCaU8PEGRUQLcOqbx5y2VVk5q+ZpgHSH7G119py4Ot7n/dn9w32SPcDA haWwKmMQTrG5k11ULaNIgK4OBbXoSqVFB+tltR6TtuHX0suKRddz1nMKn0aayvyu995R T8hr+kCc9AyRRQYWXrEuncek2wwS4aqGo3PNV95Qzfb2z/cLuESkaO/MiJLBq4Aarlf2 9K9KswScwIv3uz2IpfcOLSBE9LiCv+m7/LEURgJteBQtnp2rbYTe1Bdz2cvKM4KSLYlW Eo+w== X-Gm-Message-State: AGi0PuayeK29wHhKSl/dorNRFS6/aCUUPgv5bZzz6rT5ewcdu50thTbI tlbAyhX2DHG+bq9ZlxoJ/2c= X-Google-Smtp-Source: APiQypKKENrG0wlOjGqKZJ5An1gkwndU6fVXfEAr9ac0JndRmthMNo4kt+ZCJgtgyWpgIS5PNL79jQ== X-Received: by 2002:a17:902:e788:: with SMTP id cp8mr4627731plb.343.1585861174587; Thu, 02 Apr 2020 13:59:34 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id x17sm396140pfm.55.2020.04.02.13.59.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2020 13:59:33 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 52AA940254; Thu, 2 Apr 2020 20:59:32 +0000 (UTC) Date: Thu, 2 Apr 2020 20:59:32 +0000 From: Luis Chamberlain To: Kees Cook Cc: Vlastimil Babka , Iurii Zaikin , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-mm@kvack.org, Ivan Teterevkov , Michal Hocko , David Rientjes , Matthew Wilcox , "Eric W . Biederman" , "Guilherme G . Piccoli" , Alexey Dobriyan , Thomas Gleixner , Greg Kroah-Hartman , Christian Brauner Subject: Re: [PATCH 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line Message-ID: <20200402205932.GM11244@42.do-not-panic.com> References: <20200330115535.3215-1-vbabka@suse.cz> <20200330115535.3215-2-vbabka@suse.cz> <20200330224422.GX11244@42.do-not-panic.com> <287ac6ae-a898-3e68-c7d8-4c1d17a40db9@suse.cz> <20200402160442.GA11244@42.do-not-panic.com> <202004021017.3A23B759@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202004021017.3A23B759@keescook> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 02, 2020 at 10:23:13AM -0700, Kees Cook wrote: > On Thu, Apr 02, 2020 at 04:04:42PM +0000, Luis Chamberlain wrote: > > On Wed, Apr 01, 2020 at 01:01:47PM +0200, Vlastimil Babka wrote: > > > On 3/31/20 12:44 AM, Luis Chamberlain wrote: > > > >> + } else if (wret != len) { > > > >> + pr_err("Wrote only %ld bytes of %d writing to proc file %s to set sysctl parameter '%s=%s'", > > > >> + wret, len, path, param, val); > > > >> + } > > > >> + > > > >> + err = filp_close(file, NULL); > > > >> + if (err) > > > >> + pr_err("Error %pe closing proc file to set sysctl parameter '%s=%s'", > > > >> + ERR_PTR(err), param, val); > > > >> +out: > > > >> + kfree(path); > > > >> + return 0; > > > >> +} > > > >> + > > > >> +void do_sysctl_args(void) > > > >> +{ > > > >> + char *command_line; > > > >> + struct vfsmount *proc_mnt = NULL; > > > >> + > > > >> + command_line = kstrdup(saved_command_line, GFP_KERNEL); > > > > > > > > can you use kstrndup() ? And then use kfree_const()? Yes, feel free to > > > > > > I don't follow, what am I missing? Do you mean this? > > > > > > size_t len = strlen(saved_command_line); > > > command_line = kstrndup(saved_command_line, len, GFP_KERNEL); > > > > > > What would be the advantage over plain kstrdup()? > > > As for kfree_const(), when would command_line be .rodata? I don't see using > > > kstrndup() resulting in that. > > > > The const nature of using kstrdup() comes with using const for your > > purpose. ie: > > > > const char *const_command_line = saved_command_line; > > > > The point of a kstrncpy() then is to ensure force a const throughout > > your use if you know you don't need modifications. > > I'm not following this suggestion. It _is_ modifying it. That's why it's > making a copy. What am I missing? We modify the copied bootparams to allow new sysctls to map to old boot params? If so, then yes, this cannot be used. > > > >> + parse_args("Setting sysctl args", command_line, > > > >> + NULL, 0, -1, -1, &proc_mnt, process_sysctl_arg); > > > >> + > > > >> + if (proc_mnt) > > > >> + kern_unmount(proc_mnt); > > > >> + > > > >> + kfree(command_line); > > > >> +} > > > > > > > > Then, can we get this tested as part of lib/test_sysctl.c with its > > > > respective tools/testing/selftests/sysctl/sysctl.sh ? > > > > > > Hmm so I add some sysctl to the test "module" (in fact the 'config' file says it > > > should be build with 'y', which would be needed anyway) and expand the test > > > instructions so that the test kernel boot has to include it on the command line, > > > and then I verify it has been set? Or do you see a better way? > > > > We don't necessarily have a way to test the use boot params today. > > That reveals an are which we should eventually put some focus on > > in the future. In the meantime we have to deal with what we have. > > > > So let's think about this: > > > > You are adding a new cmdline sysctl boot param, and also a wrapper > > for those old boot bootparams to also work using both new sysctl > > path and old path. Testing just these both should suffice. > > > > How about this: > > > > For testing the new feature you are adding, can you extend the default > > boot params *always* if a new CONFIG_TEST_SYSCTL_CMDLINE is set? Then > > upon boot we can verify the proc handlers for these new boot params got > > kicked, and likewise some other proc handlers which also can be used > > from the cmdline are *not* set. For this later set, we already have > > a series of test syctls you can use. In fact, you can use the existing > > syctls for both cases already I believe, its just a matter of adding > > this new CONFIG_TEST_SYSCTL_CMDLINE which would extend the cmdline, > > and these tests would take place *first* on the script. > > This seems... messy. It is all we have. > I'm all for testing this, OK so we do want to test it. > but I'd rather this not be internally driven. This is the least cumbersome solution I could think of. Other things would require things like using qemu, etc. That seems much more messsy. > This is an external interface (boot params), so > I'd rather an external driver handle that testing. We don't have a > common method to do that with the kernel, though. Right... which begs the question now -- how do we test this sort of stuff? The above would at least get us coverage while we iron something more generic out for boot params. > > That would test both cases with one kernel. > > > > You could then also add a bogus new sysctl which also expands to a silly > > raw boot param to test the wrapper you are providing. That would be the > > only new test syctl you would need to add. > > Sure, that seems reasonable. Supporting externally driven testing makes > sense for this. But again, what exactly? Luis