linux-kernel - Re: [RFC PATCH 0/5] Arch-independent livepatch

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, 11 Nov 2015 15:00:44 +0100 (CET)
From:	Miroslav Benes <mbenes@...e.cz>
To:	Jessica Yu <jeyu@...hat.com>
cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Seth Jennings <sjenning@...hat.com>,
	Jiri Kosina <jikos@...nel.org>,
	Vojtech Pavlik <vojtech@...e.com>, linux-api@...r.kernel.org,
	live-patching@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/5] Arch-independent livepatch

On Mon, 9 Nov 2015, Jessica Yu wrote:

> This patchset removes livepatch's need for architecture-specific relocation
> code by leveraging existing code in the module loader to perform
> arch-dependent work. Specifically, instead of duplicating code and
> re-implementing what the apply_relocate_add() function in the module loader
> already does in livepatch's klp_write_module_reloc(), we reuse
> apply_relocate_add() to write relocations. The hope is that this will make
> livepatch more easily portable to other architectures and greatly reduce
> the amount of arch-specific code required to port livepatch to a particular
> architecture.

Hi,

thanks for the patch set. I started going through it but it is gonna take 
some time. Nevertheless I've already found few things which I need to 
clarify. See respective patches.

> Background: Why does livepatch need to write its own relocations?
> ==
> A typical livepatch module contains patched versions of functions that can
> reference non-exported global symbols and non-included local symbols.
> Relocations referencing these types of symbols cannot be left in as-is
> since the kernel module loader cannot resolve them and will therefore
> reject the livepatch module. Furthermore, we cannot apply relocations that
> affect modules not loaded yet at run time (e.g. a patch to a driver). The
> current kpatch build system therefore solves this problem by embedding
> special "dynrela" (dynamic reloc) sections in the resulting patch module
> elf output. Using these dynrela sections, livepatch can correctly resolve
> symbols while taking into account its scope and what module the symbol
> belongs to, and then manually apply the dynamic relocations.

I'll only add that we solve the problem with kallsyms calls in kGraft. It 
can get really cumbersome from time to time, so this work would simplify 
our effort as well.

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/