linux-kernel - [PATCH -RFC] moduleparam: introduce core_param

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-next>] [day] [month] [year] [list]

Message-ID: <20161115020000.14057-1-paul.gortmaker@windriver.com>
Date:   Mon, 14 Nov 2016 21:00:00 -0500
From:   Paul Gortmaker <paul.gortmaker@...driver.com>
To:     <linux-kernel@...r.kernel.org>
CC:     Paul Gortmaker <paul.gortmaker@...driver.com>,
        Jessica Yu <jeyu@...hat.com>,
        Rusty Russell <rusty@...tcorp.com.au>
Subject: [PATCH -RFC] moduleparam: introduce core_param_named macro for non-modular code

We have the case where module_param_named() in file "foo.c" for
parameter myparam translates that into the bootarg for the
non-modular use case as "foo.myparam=..."

The problem exists where the use case with the filename and the
dot prefix is established, but the code is then realized to be 100%
non-modular, or is converted to non-modular.  Both of the existing
macros like core_param() or setup_param() do not append such a
prefix, so a straight conversion to either will break the existing
use cases.

Similarly, trying to embed a hard coded "foo." prefix on the name
fails cpp syntax due to the special nature of "." in code.  So we add
this parallel variant for the modular --> non-modular transition to
preserve existing and documented use cases with such a prefix.

Cc: Jessica Yu <jeyu@...hat.com>
Cc: Rusty Russell <rusty@...tcorp.com.au>
Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>
---

[Marking this RFC since I don't like the fact that it still requires
 non-modular code to use moduleparam.h -- one possible fix for that is
 to consider moving non-modular macros to a new param.h or similar. ]

 include/linux/moduleparam.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 52666d90ca94..4f2b92345eb5 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -269,6 +269,23 @@ static inline void kernel_param_unlock(struct module *mod)
 	__module_param_call("", name, &param_ops_##type, &var, perm, -1, 0)
 
 /**
+ * core_param_named - define a module compat core kernel parameter.
+ * @name: the name of the cmdline and sysfs parameter (often the same as var)
+ * @var: the variable
+ * @type: the type of the parameter
+ * @perm: visibility in sysfs
+ *
+ * core_param_named is just like module_param_named(), but cannot be modular
+ * and it _does_ add a prefix (such as "printk.").  This is for compatibility
+ * with module_param_named(), and it exists to provide boot arg compatibility
+ * with code that was previously using the modular version with the prefix.
+ */
+#define core_param_named(name, var, type, perm)				\
+	param_check_##type(name, &(var));				\
+	__module_param_call(KBUILD_MODNAME ".", name, &param_ops_##type,\
+			    &var, perm, -1, 0)
+
+/**
  * core_param_unsafe - same as core_param but taints kernel
  */
 #define core_param_unsafe(name, var, type, perm)		\
-- 
2.10.1