linux-kernel - Re: [PATCH v2] livepatch: old_name.number scheme in livepatch sysfs directory

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:	Wed, 4 Nov 2015 10:03:54 -0600
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Miroslav Benes <mbenes@...e.cz>
Cc:	Chris J Arges <chris.j.arges@...onical.com>,
	live-patching@...r.kernel.org, jeyu@...hat.com,
	Seth Jennings <sjenning@...hat.com>,
	Jiri Kosina <jikos@...nel.org>,
	Vojtech Pavlik <vojtech@...e.com>, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] livepatch: old_name.number scheme in livepatch sysfs
 directory

On Wed, Nov 04, 2015 at 10:52:52AM +0100, Miroslav Benes wrote:
> On Tue, 3 Nov 2015, Josh Poimboeuf wrote:
> > > Object entry would be empty for not loaded object. I would not 
> > > dare to propose to remove such object entries. It would make things worse. 
> > 
> > Why would removing an empty object entry make things worse?
> 
> I think it all comes down to a question whether the sysfs entries say what 
> a patch is capable to patch or what this patch is currently patching in 
> the system. I am inclined to the former so the removal would make me 
> nervous. But I am not against the second approach. We are still in testing 
> mode as far as sysfs is concerned so we can try even harsh changes and see 
> how it's gonna go.

I see your point.  This approach only describes what is patched now, but
it doesn't describe what *will* be patched.  Ideally we could find a way
to describe both.

Speaking of harsh changes, here's an idea.

What if we require the patch author to supply the value of 'n' instead
of supplying the symbol address?  We could get rid of 'old_addr' as an
input in klp_func and and replace it with 'old_sympos' which has the
value of 'n'.  Or alternatively we could require old_name to be of the
format "func,n".

That would uniquely identify each patched function, even _before_ the
object is loaded.

It would also fix another big problem we have today, where there's no
way to disambiguate duplicate symbols in modules, for both function
addresses and for relocs.

It would simplify the code in other places as well: no special handling
for kASLR, no need for klp_verify_vmlinux_symbol() vs
klp_find_object_symbol().

A drawback is that it requires the patch author to do a little more due
diligence when filling out klp_func.  But we already require them to be
careful.

Thoughts?

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