linux-kernel - Re: [for-next][PATCH 04/26] bootconfig: Add Extra Boot Config 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]

Message-ID: <20200210174053.GD29627@zn.tnic>
Date:   Mon, 10 Feb 2020 18:40:53 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [for-next][PATCH 04/26] bootconfig: Add Extra Boot Config support

On Tue, Feb 11, 2020 at 12:10:07AM +0900, Masami Hiramatsu wrote:
> Sure, there are some examples under Documentation/trace/boottime-trace.rst.
> Since the tracefs (ftrace's filesystem user interface) is extensible
> by dynamic events and instanses, I need flexibility of option "keys"
> not only values, also I need structured settings because some keys
> will configure same events or trace instance.

 [ ... ]

Yap, gotcha. It makes a lot of sense for you guys because you don't want
to be typing all those long ftrace command lines on every boot. And the
command line in grub can become too long and hard to handle too.

> 1) write a following bootconfig file
> ----
> kernel {
> 	# root device and resume devices
> 	root = /dev/disk/by-id/nvme-eui.0025385481b2fe2a-part2
> 	resume = /dev/disk/by-id/nvme-eui.0025385481b2fe2a-part1
> 	ro			# Mount root device readonly.
> 	debug			# boot with debug log
> 	ignore_loglevel	# this will print all messages
> 	log_buf_len = 16M	# So expand log buffer to 16MB
> 	no_console_suspend	# Debugging suspend process
> 	mem_encrypt = off	# Set AMD SME to off
> }
> 
> init {
> 	net.ifnames = 0	# Use tradisional ifname
> 	systemd.log_target = null	# Ignore systemd log?
> }

Ok.

However, this has a downside. When you request dmesg from a user because
you're debugging an issue - and we do that all the time - if the command
line were in a config file, we would have to see that config file too.

VS now, it is simply in dmesg.

> Boot time tracing is just a example. I think we can expand this for some
> other subsystems too. And this might be also helpful for adding a bit more
> complex syntax to those parameters without parser.

Yes, I think I see it now. And I still don't think you want this enabled
by default on every box. It is expressed perfectly fine here:

config BOOTTIME_TRACING
        bool "Boot-time Tracing support"
        depends on BOOT_CONFIG && TRACING

so if distros want to enable that, they will enable BOOT_CONFIG too,
transitively. And other subsystems would simply depend on it the same if
they wanna use bootconfig.

But the way we supply command line args now ain't broke. And they normal
user doesn't care - grub simply pastes them everywhere.

Don't get me wrong - I don't mind using a bootconfig. I simply don't see
a compelling argument to have it enabled everywhere and by default and
think that other stuff selecting it is perfectly fine. IMO, of course.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette