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:	Thu, 18 Jun 2015 09:59:28 +0800
From:	Li Bin <huawei.libin@...wei.com>
To:	Miroslav Benes <mbenes@...e.cz>
CC:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Seth Jennings <sjenning@...hat.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Vojtech Pavlik <vojtech@...e.cz>,
	<live-patching@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<xiexiuqi@...wei.com>
Subject: Re: [PATCH] livepatch: add sysfs interface /sys/kernel/livepatch/state

On 2015/6/17 21:20, Miroslav Benes wrote:
> On Wed, 17 Jun 2015, Li Bin wrote:
> 
>> On 2015/6/17 16:13, Miroslav Benes wrote:
>>> On Wed, 17 Jun 2015, Li Bin wrote:
>>
>>> The list of applied patches can be obtained just by 'ls 
>>> /sys/kernel/livepatch' and their state is in enabled attribute in each 
>>> respective patch (no, you cannot obtain the order in the stack).
>>
>> But why we cannot obtain it? I think We indeed need the stack order when we
>> will disable one patch, at least, we can find out whether it is on the top of
>> the stack if failed to disable one patch.
> 
> I meant with the current means. It is correct that we do not export 
> information about stacking order anywhere.
> 
> What we do in kGraft is that there is something like refcount for each 
> patch. When the patch is being applied the refcount of all the previous 
> patches is increased. Only the patch with the refcount equal to 0 can be 
> removed. This information is exported and gives one a clue about the 
> order.
> 

It sounds good, but the information is limited that cannot show the stack
order, right? (The refcount of all the disabled patch is equal to 0, if
being enable one disabled patch, the stack order is also needed.)

refcount Patch
-------------------
3	patch1(enabled)
2	patch2(enabled)
1	patch3(enabled)
0	patch4(enabled)
0	patch5(disabled)
0	patch6(disabled)

Unless the refcount is allowed to be less than 0, then when the patch is
being disabled the refcount of all the patches is decreased, when the patch
is being enabled the refcount of all patches is increased. Only the patch
with the refcount equal to 0 can be disabled and only equal to -1 can be
enabled, and only less or equal to 0 can be removed (that the livepatch does
not support right now).

refcount Patch
-------------------
3	patch1(enabled)
2	patch2(enabled)
1	patch3(enabled)
0	patch4(enabled)
-1	patch5(disabled)
-2	patch6(disabled)

Thanks,
	Li Bin

> So if there is a need to have something like this there would certainly 
> be a way (or ways to be precise) how to do it. The question is if we need 
> it right now.
> 
> Regards,
> Miroslav
> 
> .
> 


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ