linux-kernel - Re: klp: make object/func-walking helpers more robust

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: <alpine.LNX.2.00.1604291032450.27368@cbobk.fhfr.pm>
Date:	Fri, 29 Apr 2016 10:35:29 +0200 (CEST)
From:	Jiri Kosina <jikos@...nel.org>
To:	Jessica Yu <jeyu@...hat.com>
cc:	Miroslav Benes <mbenes@...e.cz>, jpoimboe@...hat.com,
	pmladek@...e.com, live-patching@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: klp: make object/func-walking helpers more robust

On Thu, 28 Apr 2016, Jessica Yu wrote:

> > #define klp_for_each_object(patch, obj) \
> > -	for (obj = patch->objs; obj->funcs; obj++)
> > +	for (obj = patch->objs; obj->funcs || obj->name; obj++)
> 
> Remember that for patches to vmlinux, obj->name and obj->mod will also
> both be NULL. So if someone happens to forget to fill in obj->funcs
> for a vmlinux patch, we won't catch that case here. Perhaps we need a
> better way of determining whether we've reached the end of the array,
> or determining that the struct is truly empty..

I'd rather not over-compilcate it.

Admittedly, the change in the termination condition catches most of the 
errors made by the patch author, but not all.
But there are many other places in the kernel where inserting an empty 
item into the middle of statically initialized array will make the whole 
thing explode, so let's not try to be more clever than necessary.

I plan to queue Miroslav's patch unless there are serious objections 
raised.

Thanks,

-- 
Jiri Kosina
SUSE Labs