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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 E83E3C2BA17 for ; Fri, 3 Apr 2020 23:57:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 83AC92074B for ; Fri, 3 Apr 2020 23:57:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="QEtE6aol" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83AC92074B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0AA978E0008; Fri, 3 Apr 2020 19:57:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05BCA8E0007; Fri, 3 Apr 2020 19:57:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB1C78E0008; Fri, 3 Apr 2020 19:57:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id CBFED8E0007 for ; Fri, 3 Apr 2020 19:57:55 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7A553180AD81F for ; Fri, 3 Apr 2020 23:57:55 +0000 (UTC) X-FDA: 76668209310.04.quiet83_28051438a9c40 X-HE-Tag: quiet83_28051438a9c40 X-Filterd-Recvd-Size: 9155 Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Fri, 3 Apr 2020 23:57:54 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id b72so4384286pfb.11 for ; Fri, 03 Apr 2020 16:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UPVAT2L8fukLZnuc3+5vueRjOJrPf8klG/eXO9o8hxw=; b=QEtE6aolufF+32AwcMQjO4gb9bIL99mZp48e8c01C1msnBx3pQym12/IQ+LgE/ux3F CVcMLTu06BWrANlH++15E5ZtzRpx/dHJ2ATqpFT+gejRbnrdSa0e/lZedv2fq2fc1xWF p6HKmiz+g/AW2y250AEiEIm0nKlW0sXeqbLuM= 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; bh=UPVAT2L8fukLZnuc3+5vueRjOJrPf8klG/eXO9o8hxw=; b=X/Z+xu8fngHaC0G8pP/5sj+GsntP5h6DI864SkBEbI+6Lsu6TpeSjE+qivZ9s9nuaJ y0IwjVyn2pBtTgdb7iXn6SomcW06DoK8JFEReKlN9/9o7oAdaMaLfJSPGVZyUlsOpyoM WsLt4TQV2aWe2WgjkvJezzwT2T4XA96ySY4iXIRZt+bXpvRN+8F3xYiAxyBqgfkLN7z7 bjxr1gyipB/CgN7PIiq0XWG6EAVFEM1DNiZhyshzgd2e9NEuU09szRGlAMq6r147mEoN aOF0AS2Ok4MEn6ZgVXXrYOXRzQIT6AnrW8qUE7fbIp26JuI18vrxzRMOP77d8yfijDe0 Lf/g== X-Gm-Message-State: AGi0Puagje7RTtvFCTTPdDxfuQ+htDTeWtKt9MfpMPnvJjmZVKBSVSf/ 6qj+wnsEGV0R76xu/HNAvTIt3g== X-Google-Smtp-Source: APiQypLaamdlVDp6BoXHF0qVh4WK6KwXWUcTKrfXP1OuIDxH+nfTux9xP69euEIaJLF5YWHtAAFDRg== X-Received: by 2002:a63:ce4a:: with SMTP id r10mr10771972pgi.225.1585958273804; Fri, 03 Apr 2020 16:57:53 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id y131sm6528000pfb.78.2020.04.03.16.57.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Apr 2020 16:57:52 -0700 (PDT) Date: Fri, 3 Apr 2020 16:57:51 -0700 From: Kees Cook To: Luis Chamberlain 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: <202004031654.C4389A04EF@keescook> 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> <20200402205932.GM11244@42.do-not-panic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200402205932.GM11244@42.do-not-panic.com> 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 08:59:32PM +0000, Luis Chamberlain wrote: > 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. I feel like I've lost track of this thread. This strdup is so that the command line can have '\0's injected while it steps through the args (and for doing the . and / replacement). I don't know what you mean by "map" here: this is standard parse_args() usage. > > > > >> + 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. Yes. Doing an internal extension isn't testing the actual code. > > > 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? I don't think anything is needed for this series. It can be boot tested manually. -- Kees Cook