Re: [PATCH -repost 05/21] kgr: update Kconfig documentation

From: Jiri Kosina
Date: Thu Jun 26 2014 - 04:34:13 EST


On Thu, 26 Jun 2014, Jiri Slaby wrote:

> >> ---
> >> kernel/Kconfig.kgraft | 3 +++
> >> samples/Kconfig | 4 ++++
> >> 2 files changed, 7 insertions(+)
> >>
> >> diff --git a/kernel/Kconfig.kgraft b/kernel/Kconfig.kgraft
> >> index f38d82c06580..bead93646071 100644
> >> --- a/kernel/Kconfig.kgraft
> >> +++ b/kernel/Kconfig.kgraft
> >> @@ -5,3 +5,6 @@ config KGRAFT
> >> bool "kGraft infrastructure"
> >> depends on DYNAMIC_FTRACE_WITH_REGS
> >> depends on HAVE_KGRAFT
> >> + help
> >> + Select this to enable kGraft online kernel patching. The
> >> + runtime price is zero, so it is safe to say Y here.
> >> diff --git a/samples/Kconfig b/samples/Kconfi
> >
> > The runtime impact is that you've just introduced a virus and trojan
> > writers delight into your kernel. There's a balance between convenience
> > and security but given most users will never use kgraft this advice seems
> > incorrect.
>
> This now writes:
> + help
> + Select this to enable kGraft online kernel patching. The
> + runtime price is nearly zero, so it is safe to say Y here
> + provided you are aware of all the consequences (e.g. in
> + security).
>
> Is it OK with you?

This might cause a false impression that we are actually opening a
security hole into a system, which is not true at all.

Yes, backdoor writeres might (or might not) make use of kGraft API, but
they have gazillion of other comparable options (*probes, ftrace,
text_poke(), ...).

I'd perhaps propose something like

"Select this to enable kGraft live kernel patching. The runtime penalty is
nearly zero, so it is safe to say Y here if you want the kernel to expose
API for live patching to modules".

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