All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Jiri Slaby <jslaby@suse.cz>
Cc: Jiri Kosina <jkosina@suse.cz>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, tj@kernel.org, rostedt@goodmis.org,
	mingo@redhat.com, akpm@linux-foundation.org, andi@firstfloor.org,
	paulmck@linux.vnet.ibm.com, jirislaby@gmail.com,
	Vojtech Pavlik <vojtech@suse.cz>, Michael Matz <matz@suse.de>,
	Udo Seidel <udoseidel@gmx.de>
Subject: Re: [PATCH -repost 05/21] kgr: update Kconfig documentation
Date: Fri, 4 Jul 2014 12:35:05 +0200	[thread overview]
Message-ID: <20140704103505.GB19252@amd.pavel.ucw.cz> (raw)
In-Reply-To: <53B6708E.5030106@suse.cz>

On Fri 2014-07-04 11:14:54, Jiri Slaby wrote:
> On 06/27/2014 09:18 PM, Pavel Machek wrote:
> >>> 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".

It is "safe" but completely stupid to say Y here, unless you are a
distro vendor.

> > Well. People that are not distro vendors will not prepare patches for
> > themselves, right?
> 
> Hi, why do you believe so? But it is not so important, see below.

Because it is quite hard to prepare the patch, and there's not really
enough documentation..? And given choice between "spend half an hour
preparing patch" and "just reboot", people compiling their own kernels
know what to do...

> > And patches prepared for suse will not work on
> > self-configured kernels.
> > 
> > So probably everyone should say "N" here...
> 
> The text is formulated correctly and satisfies your concerns, I think.
> Say Y, if you want the API...

Lawyer may read it correctly. For the rest of human beings, it should
say "say N here". Three people in the world that can prepare the patch
know they need the option  enabled, even without help text.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2014-07-04 10:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25 11:06 [PATCH -repost 01/21] ftrace: Add function to find fentry of function Jiri Slaby
2014-06-25 11:06 ` [PATCH -repost 02/21] ftrace: Make ftrace_is_dead available globally Jiri Slaby
2014-06-25 11:06 ` [PATCH -repost 03/21] kgr: initial code Jiri Slaby
2014-06-25 11:06 ` [PATCH -repost 04/21] kgr: add testing kgraft patch Jiri Slaby
2014-06-25 11:06 ` [PATCH -repost 05/21] kgr: update Kconfig documentation Jiri Slaby
2014-06-25 12:42   ` One Thousand Gnomes
2014-06-26  8:25     ` Jiri Slaby
2014-06-26  8:34       ` Jiri Kosina
2014-06-27 19:18         ` Pavel Machek
2014-07-04  9:14           ` Jiri Slaby
2014-07-04 10:35             ` Pavel Machek [this message]
2014-07-05 19:47               ` Jiri Kosina
2014-07-06 12:35                 ` Pavel Machek
2014-06-25 11:07 ` [PATCH -repost 06/21] kgr: add Documentation Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 07/21] kgr: trigger the first check earlier Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 08/21] kgr: sched.h, introduce kgr_task_safe helper Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 09/21] kgr: mark task_safe in some kthreads Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 10/21] kgr: kthreads support Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 11/21] kgr: handle irqs Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 12/21] kgr: add MAINTAINERS entry Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 13/21] kgr: x86: refuse to build without fentry support Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 14/21] kgr: add procfs interface for per-process 'kgr_in_progress' Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 15/21] kgr: make a per-process 'in progress' flag a single bit Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 16/21] kgr: add support for missing functions Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 17/21] kgr: exercise non-present function Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 18/21] kgr: fix race of stub and patching Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 19/21] kgr: expose global 'in_progress' state through procfs Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 20/21] kgr: rephrase the "kGraft failed" message Jiri Slaby
2014-06-25 11:07 ` [PATCH -repost 21/21] kgr: x86: optimize handling of CPU-bound tasks Jiri Slaby

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140704103505.GB19252@amd.pavel.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=jirislaby@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matz@suse.de \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=tj@kernel.org \
    --cc=udoseidel@gmx.de \
    --cc=vojtech@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.