linux-kernel - Re: [PATCH 2/2] livepatch: disable/enable_patch manners for interdependent patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 23 Jan 2015 09:08:14 +0800
From:	Li Bin <huawei.libin@...wei.com>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
CC:	Jiri Kosina <jkosina@...e.cz>, Seth Jennings <sjenning@...hat.com>,
	Vojtech Pavlik <vojtech@...e.cz>, Jiri Slaby <jslaby@...e.cz>,
	Miroslav Benes <mbenes@...e.cz>,
	<live-patching@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<lizefan@...wei.com>, <guohanjun@...wei.com>,
	<zhangdianfang@...wei.com>, <xiexiuqi@...wei.com>
Subject: Re: [PATCH 2/2] livepatch: disable/enable_patch manners for interdependent
 patches

On 2015/1/22 21:05, Josh Poimboeuf wrote:
> On Thu, Jan 22, 2015 at 05:54:23PM +0800, Li Bin wrote:
>> On 2015/1/22 16:39, Li Bin wrote:
>>> On 2015/1/22 11:51, Josh Poimboeuf wrote:
>>>> On Thu, Jan 22, 2015 at 08:42:29AM +0800, Li Bin wrote:
>>>>> On 2015/1/21 22:08, Jiri Kosina wrote:
>>>>>> On Wed, 21 Jan 2015, Li Bin wrote:
>>>>>> By this you limit the definition of the patch inter-dependency to just 
>>>>>> symbols. But that's not the only way how patches can depend on it other -- 
>>>>>> the dependency can be semantical.
>>>>>
>>>>> Yes, I agree with you. But I think the other dependencies such as semantical
>>>>> dependency should be judged by the user, like reverting a patch from git repository.
>>>>> Right?
>>>>
>>>> But with live patching, there are two users: the patch creator (who
>>>> creates the patch module) and the end user (who loads it on their
>>>> system).
>>>>
>>>> We can assume the patch creator knows what he's doing, but the end user
>>>> doesn't always know or care about low level details like patch
>>>> dependencies.  The easiest and safest way to protect the end user is the
>>>> current approach, which assumes that each patch depends on all
>>>> previously applied patches.
>>>
>>> But then, the feature that disable patch dynamically is useless.
>>> For example, if user find a bug be introduced by the last patch and disable
>>> it directly, the new patch is no longer allowed from now unless enable the
>>> old patch firstly but there is a risk window by this way.
>>>
>>
>> Ok, in this case we can unregister the old patch firstly.
>> But it seems that the feature that enable/disable patch dynamically indeed
>> useless. (Its value is only for the last patch to enable or disable.)
> 
> I wouldn't say it's useless... It's just a patch stack.  If there's a
> bug at the bottom of the stack, you can either:
> 
> 1) push a new patch which does the opposite of the original patch
>    (similar to how "git revert" adds a new commit);
> 
> 2) or pop everything off the stack and create a new stack to your
>    liking.
> 
> It doesn't actually prevent you from doing what you want, it just makes
> it less convenient (and more safe IMO).
> 

I am not arguing the value of the patch stack manner, but the sysfs attribute
'enabled'.

> I suppose an alternative would be to allow the patch creator to specify
> patch dependencies (in addition to something like your patch to catch
> the obvious dependencies).  But dependencies are tricky and I'm not
> really convinced that would be worth the added risk and code complexity.

Yes, since we can not assume that end users know the low level details, but they
have permission to unregister the stacktop patch, and this action will affect the
subsequent patch without providing dependencies information.

> 


--
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/