linux-kernel - Re: [PATCH 1/3] livepatch: Add klp_object and klp

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]

Message-ID: <20170825113425.GH30286@pathway.suse.cz>
Date:   Fri, 25 Aug 2017 13:34:25 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Jason Baron <jbaron@...mai.com>
Cc:     linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
        jpoimboe@...hat.com, jeyu@...nel.org, jikos@...nel.org,
        mbenes@...e.cz
Subject: Re: [PATCH 1/3] livepatch: Add klp_object and klp_func iterators

On Thu 2017-08-24 11:39:08, Jason Baron wrote:
> On 08/24/2017 10:25 AM, Petr Mladek wrote:
> > On Wed 2017-07-19 13:18:05, Jason Baron wrote:
> >> +/**
> >>   * struct klp_object - kernel object structure for live patching
> >>   * @name:	module name (or NULL for vmlinux)
> >>   * @funcs:	function entries for functions to be patched in the object
> >>   * @kobj:	kobject for sysfs resources
> >> + * @func_list:	head of list for struct klp_func_no_op
> >> + * @obj_entry:	used to link struct klp_object to struct klp_patch
> > 
> > I would prefer to make the difference between the static
> > and dynamic stuff more obvious. The generic names for both
> > variants are confusing.
> > 
> > I would personally use "no_op" in the names of list_heads related
> > to the no_op stuff. But then it would make more sense to add this
> > in the next patch.
> > 
> > Well, I do not have strong opinion about it.
> > 
> 
> I think I avoided 'no_op' in the naming because I thought it maybe could
> be a more generic list, but in practice I'm only using it for the
> dynamic noops, so I like explicitly calling it the no_ops list to make
> its usage clear. I also think it can still live in 1/2 with the 'no_op'
> name, but if that's not ok, I could just rename it in 2/2.

You could do only the needed preparation steps for the more
complicated iterator in this patch. It might still handle
only the static arrays. Then it might be extended in the 2nd patch
together with adding the extra lists.

Best Regards,
Petr