linux-kernel - Re: [PATCH] efivars: Allow disabling use as a pstore backend

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:	Tue, 12 Mar 2013 19:54:33 +0000
From:	Matt Fleming <matt.fleming@...el.com>
To:	Seth Forshee <seth.forshee@...onical.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [PATCH] efivars: Allow disabling use as a pstore backend

On Mon, 2013-03-11 at 16:17 -0500, Seth Forshee wrote:
> Here's a patch that does the command line option. I'm happy with either
> one.

I like the idea, but isn't the logic backwards? I would have expected
s/EFI_VARS_PSTORE_DEFAULT_DISABLE/EFI_VARS_PSTORE/g and then 'default y'
in the Kconfig file to maintain backward compatibility?

Is there a reason that wouldn't work?

I know that Linus has previously denounced setting new Kconfig symbols
to 'y' by default, but I think there's a case here for doing exactly
that since the previous behaviour was always enabled. The networking
folks did something similar recently, where they introduced new Kconfig
symbols for existing functionality that was previously on by default.

[...]

> +#ifdef CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE
> +static bool efivars_pstore_disable = true;
> +#else
> +static bool efivars_pstore_disable = false;
> +#endif
> +module_param_named(pstore_disable, efivars_pstore_disable, bool, 0644);
> +

static bool efivars_pstore_enable = IS_ENABLED(CONFIG_EFI_VARS_PSTORE) ?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/