linux-kernel - Re: [RFC PATCH] livepatch: allow removal of a disabled patch

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 May 2016 23:08:53 +0200 (CEST)
From:	Jiri Kosina <jikos@...nel.org>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
cc:	Miroslav Benes <mbenes@...e.cz>, jeyu@...hat.com, pmladek@...e.com,
	jslaby@...e.cz, live-patching@...r.kernel.org,
	linux-kernel@...r.kernel.org, huawei.libin@...wei.com,
	minfei.huang@...oo.com
Subject: Re: [RFC PATCH] livepatch: allow removal of a disabled patch

On Thu, 5 May 2016, Josh Poimboeuf wrote:

> I would disagree with the statement that the dynamic kobject doesn't
> scale.  We would just need a helper function to get from a kobject to
> its klp_patch.
>
> In fact, to me it seems like the right way to do it.  It doesn't make
> sense for the code which creates the kobject to be different from the
> code which initializes it.  It's slightly out of context, but
> kobject.txt does say:
> 
>   "Code which creates a kobject must, of course, initialize that object."
> 
> I view the completion as a hack to compensate for the fact that we're
> abusing the kobject interface.  And so it makes sense to me that
> CONFIG_DEBUG_KOBJECT_RELEASE would cause problems, because we're using
> kobjects in the wrong way.
> 
> So in my view, the two options are:
> 
> 1. Convert the kobject to dynamic as I described.
> 
> 2. Change the klp_register() interface so that klp_patch gets allocated
>    in livepatch code.
> 
> I'd be curious to hear what others think.

My understanding is that the concern here is that walking through the 
complete linked list every time sysfs node is accessed, just to figure out 
whether we're able to find a klp_patch entry that points back to the 
particular kobject that's being passed to the sysfs callback, isn't really 
super-efficient.

I personally wouldn't worry *that* much about that particular aspect 
(sysfs operations are hardly considered time critical anyway), but I'd 
have to think a bit more whether this is really safe wrt. deadlocks 
between kernfs locks and klp_mutex; but so far it seems to me that 
klp_mutex always nests below kernfs, so it should be OK.

Unfortunately, this still feels like a non-negligible (mis|ab)use of 
kobjects that could bite us later wrt. maintainability and general clarity 
of the code, and therefore tying klp_patch lifetime to (de)allocations 
from within livepatch code itself seems like much better idea to me.

Thanks,

-- 
Jiri Kosina
SUSE Labs