[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1412162111320.1680@pobox.suse.cz>
Date: Tue, 16 Dec 2014 21:14:37 +0100 (CET)
From: Jiri Kosina <jkosina@...e.cz>
To: Balbir Singh <bsingharora@...il.com>
cc: Seth Jennings <sjenning@...hat.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Vojtech Pavlik <vojtech@...e.cz>,
Steven Rostedt <rostedt@...dmis.org>,
Petr Mladek <pmladek@...e.cz>, Miroslav Benes <mbenes@...e.cz>,
Christoph Hellwig <hch@...radead.org>,
Greg KH <gregkh@...uxfoundation.org>,
Andy Lutomirski <luto@...capital.net>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
live-patching@...r.kernel.org, x86@...nel.org, kpatch@...hat.com,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv7 0/3] Kernel Live Patching
On Tue, 16 Dec 2014, Balbir Singh wrote:
> Could you describe what this does to signing? I presume the patched
> module should cause a taint on module signing?
Hmm, why should it?
- if module signatures are enforced on the system in question, the module
with the patch itself has to be signed as well, otherwise it will not be
loaded by the kernel at all in the first place
- after the trusted (signed) module with the patch is loaded, this is in
principle no way different than other self-modifications the kernel is
performing all the time (static keys, alternatives, kprobes, ...)
Yes, we are tainting a kernel, but for reasons completely unrelated to
module signing.
I actually think that module signing doesn't play any role whatsoever in
what this patchset is doing.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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/
Powered by blists - more mailing lists