linux-kernel - Re: [RFC PATCH v3 01/19] skc: Add supplemental kernel cmdline support

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]

Date:   Mon, 26 Aug 2019 08:27:48 -0500
From:   Rob Herring <robh+dt@...nel.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Frank Rowand <frowand.list@...il.com>,
        Ingo Molnar <mingo@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Tim Bird <Tim.Bird@...y.com>, Jiri Olsa <jolsa@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Tom Zanussi <tom.zanussi@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v3 01/19] skc: Add supplemental kernel cmdline support

On Sun, Aug 25, 2019 at 10:15 PM Masami Hiramatsu <mhiramat@...nel.org> wrote:
>
> Supplemental kernel command line (SKC) allows admin to pass a
> tree-structured supplemental kernel commandline file (SKC file)
> when boot up kernel. This expands the kernel command line in
> efficient way.
>
> SKC file will contain some key-value commands, e.g.
>
> key.word = value1;
> another.key.word = value2;
>
> It can fold same keys with braces, also you can write array
> data. For example,
>
> key {
>    word1 {
>       setting1 = data;
>       setting2;
>    }
>    word2.array = "val1", "val2";
> }

Why invent a custom file format? You could use YAML (or JSON):

key:
 word1:
  setting1: data
  setting2: true
 word2:
  - val1
  - val2

That would allow you to define a schema for defined options and can
easily be manipulated with python (or any language with dictionaries
and lists). That does imply adding a YAML parser to the kernel which
I'm not sure is a great idea. There is a C parser lib, but working
with YAML in C is not that great compared to python.

Another option would be using the DTS format, but as a separate file.
That's not unprecedented as u-boot FIT image is a DTB. Then the kernel
already has the parser. And you could still have schema now.

A new interface will take a lot of bootloader work to make it easy to
use given the user has to manually load some file in the bootloader
and know a good address to load it to. Between that and rebuilding the
kernel with the configuration, I'd pick rebuilding the kernel. Perhaps
this version will highlight that the original proposal was not so bad.

Another thought, maybe you could process the configuration file that's
in a readable/editable format into a flat representation that could
simply be added to the kernel command line:

key.word1.setting1=data key.word1.setting2 key.word2=val1,val2

That would then use an existing interface and probably simplify the
kernel parsing.

Rob