Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 18 Oct 2018 10:30:27 -0500
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     Petr Mladek <pmladek@suse.com>
Cc:     Miroslav Benes <mbenes@suse.cz>, Jiri Kosina <jikos@kernel.org>,
        Jason Baron <jbaron@akamai.com>,
        Joe Lawrence <joe.lawrence@redhat.com>,
        Jessica Yu <jeyu@kernel.org>,
        Evgenii Shatokhin <eshatokhin@virtuozzo.com>,
        live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v12 06/12] livepatch: Simplify API by removing
 registration step
Message-ID: <20181018153027.x4nk2ihgs5ehsln2@treble>
References: <20180828143603.4442-1-pmladek@suse.com>
 <20180828143603.4442-7-pmladek@suse.com>
 <alpine.LSU.2.21.1809051108440.7768@pobox.suse.cz>
 <20181012130120.f5berowklyccd7lj@pathway.suse.cz>
 <alpine.LSU.2.21.1810151756290.11383@pobox.suse.cz>
 <20181018145456.nrekm2iuyf5ztw3n@pathway.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20181018145456.nrekm2iuyf5ztw3n@pathway.suse.cz>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Oct 18, 2018 at 04:54:56PM +0200, Petr Mladek wrote:
> On Mon 2018-10-15 18:01:43, Miroslav Benes wrote:
> > On Fri, 12 Oct 2018, Petr Mladek wrote:
> > 
> > > On Wed 2018-09-05 11:34:06, Miroslav Benes wrote:
> > > > On Tue, 28 Aug 2018, Petr Mladek wrote:
> > > > > Also the API and logic is much easier. It is enough to call
> > > > > klp_enable_patch() in module_init() call. The patch patch can be disabled
> > > > > by writing '0' into /sys/kernel/livepatch/<patch>/enabled. Then the module
> > > > > can be removed once the transition finishes and sysfs interface is freed.
> > > > 
> > > > I think it would be good to discuss our sysfs interface here as well.
> > > > 
> > > > Writing '1' to enabled attribute now makes sense only when you need to 
> > > > reverse an unpatching transition. Writing '0' means "disable" or a 
> > > > reversion again.
> > > > 
> > > > Wouldn't be better to split it to two different attributes? Something like 
> > > > "disable" and "reverse"? It could be more intuitive.
> > > > 
> > > > Maybe we'd also find out that even patch->enabled member is not useful 
> > > > anymore in such case.
> > > 
> > > I though about this as well. I kept "enabled" because:
> > > 
> > >   + It keeps the public interface the same as before. Most people
> > >     would not notice any change in the behavior except maybe that
> > >     the interface disappears when the patch gets disabled.
> > 
> > Well our sysfs interface is still in a testing phase as far as ABI is 
> > involved. Moreover, each live patch is bound to its base kernel by 
> > definition anyway. So we can change this without remorse, I think.

But it would break tooling, which is not kernel specific.  I'm not sure
whether it would be worth the headache.  After all I think the livepatch
sysfs interface is designed for tools, not humans.

> > >   + The reverse operation makes most sense when the transition
> > >     cannot get finished. In theory, it might be problem to
> > >     finish even the reversed one. People might want to
> > >     reverse once again and force it. Then "reverse" file
> > >     might be confusing. They might not know in which direction
> > >     they do the reverse.
> > 
> > I still think it would be better to have a less confusing interface and it 
> > would outweigh the second remark.
> 
> OK, what about having just "disable" in sysfs. I agree that it makes
> much more sense than "enable" now.
> 
> It might be used also for the reverse operation the same way as
> "enable" was used before. I think that standalone "reverse" might
> be confusing when we allow to reverse the operation in both
> directions.

As long as we're talking about radical changes... how about we just
don't allow disabling patches at all?  Instead a patch can be replaced
with a 'revert' patch, or an empty 'nop' patch.  That would make our
code simpler and also ensure there's an audit trail.

(Apologies if we've already talked about this.  My brain is still mushy
thanks to Spectre and friends.)

The amount of flexibility we allow is kind of crazy, considering how
delicate of an operation live patching is.  That reminds me that I
should bring up my other favorite idea at LPC: require modules to be
loaded before we "patch" them.

-- 
Josh