All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	Iurii Zaikin <yzaikin@google.com>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	linux-mm@kvack.org, Ivan Teterevkov <ivan.teterevkov@nutanix.com>,
	Michal Hocko <mhocko@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	"Guilherme G . Piccoli" <gpiccoli@canonical.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Christian Brauner <christian.brauner@ubuntu.com>
Subject: Re: [PATCH 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line
Date: Mon, 6 Apr 2020 14:08:36 +0000	[thread overview]
Message-ID: <20200406140836.GA11244@42.do-not-panic.com> (raw)
In-Reply-To: <202004031654.C4389A04EF@keescook>

On Fri, Apr 03, 2020 at 04:57:51PM -0700, Kees Cook wrote:
> On Thu, Apr 02, 2020 at 08:59:32PM +0000, Luis Chamberlain wrote:
> > We modify the copied bootparams to allow new sysctls to map to old boot params?
> 
> 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).

Please ignore the const feedback then.

> > 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.

But it would.

> > > 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.

Why test it manually when it could be tested automatically with a new kconfig?

  Luis

  reply	other threads:[~2020-04-06 14:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30 11:55 [PATCH 0/3] support setting sysctl parameters from kernel command line Vlastimil Babka
2020-03-30 11:55 ` [PATCH 1/3] kernel/sysctl: " Vlastimil Babka
2020-03-30 16:23   ` Vlastimil Babka
2020-03-30 17:40     ` Kees Cook
2020-03-30 17:39   ` Kees Cook
2020-03-30 20:15   ` kbuild test robot
2020-03-31 18:29     ` Kees Cook
2020-03-30 22:44   ` Luis Chamberlain
2020-03-31  7:42     ` Vlastimil Babka
2020-03-31  7:48       ` Michal Hocko
2020-03-31 18:26         ` Kees Cook
2020-03-31 14:31       ` Luis Chamberlain
2020-04-01 11:01     ` Vlastimil Babka
2020-04-02 16:04       ` Luis Chamberlain
2020-04-02 17:23         ` Kees Cook
2020-04-02 20:59           ` Luis Chamberlain
2020-04-03 23:57             ` Kees Cook
2020-04-06 14:08               ` Luis Chamberlain [this message]
2020-04-06 15:58                 ` Kees Cook
2020-04-06 17:08                   ` Luis Chamberlain
2020-04-14 11:25                     ` Vlastimil Babka
2020-04-15  3:23                       ` Masami Hiramatsu
2020-04-15  6:08                       ` Luis Chamberlain
2020-03-30 11:55 ` [PATCH 2/3] kernel/sysctl: support handling command line aliases Vlastimil Babka
2020-03-30 17:41   ` Kees Cook
2020-03-31 14:35   ` Luis Chamberlain
2020-03-30 11:55 ` [PATCH 3/3] kernel/hung_task convert hung_task_panic boot parameter to sysctl Vlastimil Babka
2020-03-30 17:43   ` Kees Cook
2020-03-31  0:34     ` John Hubbard
2020-03-31  7:27       ` Vlastimil Babka
2020-03-31 15:49         ` John Hubbard
2020-03-31 23:12   ` Tetsuo Handa
2020-04-01  8:47     ` Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200406140836.GA11244@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=ebiederm@xmission.com \
    --cc=gpiccoli@canonical.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ivan.teterevkov@nutanix.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=yzaikin@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.