[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1479082460.240606063@decadent.org.uk>
Date: Mon, 14 Nov 2016 00:14:20 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC: akpm@...ux-foundation.org, "Rusty Russell" <rusty@...tcorp.com.au>
Subject: [PATCH 3.16 114/346] Documentation/module-signing.txt: Note need
for version info if reusing a key
3.16.39-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <ben@...adent.org.uk>
commit b8612e517c3c9809e1200b72c474dbfd969e5a83 upstream.
Signing a module should only make it trusted by the specific kernel it
was built for, not anything else. If a module signing key is used for
multiple ABI-incompatible kernels, the modules need to include enough
version information to distinguish them.
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>
---
Documentation/module-signing.txt | 6 ++++++
1 file changed, 6 insertions(+)
--- a/Documentation/module-signing.txt
+++ b/Documentation/module-signing.txt
@@ -239,3 +239,9 @@ Since the private key is used to sign mo
the private key to sign modules and compromise the operating system. The
private key must be either destroyed or moved to a secure location and not kept
in the root node of the kernel source tree.
+
+If you use the same private key to sign modules for multiple kernel
+configurations, you must ensure that the module version information is
+sufficient to prevent loading a module into a different kernel. Either
+set CONFIG_MODVERSIONS=y or ensure that each configuration has a different
+kernel release string by changing EXTRAVERSION or CONFIG_LOCALVERSION.
Powered by blists - more mailing lists