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
| ||
|
Date: Thu, 7 Jul 2016 17:56:33 +0200 From: Petr Mladek <pmladek@...e.com> To: Jessica Yu <jeyu@...hat.com> Cc: Josh Poimboeuf <jpoimboe@...hat.com>, Miroslav Benes <mbenes@...e.cz>, Jiri Kosina <jikos@...nel.org>, Chris J Arges <chris.j.arges@...onical.com>, Eugene Shatokhin <eugene.shatokhin@...alab.ru>, live-patching@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/2] Fix issue with alternatives/paravirt patches On Tue 2016-07-05 22:34:58, Jessica Yu wrote: > Hi, > > A few months ago, Chris Arges reported a bug involving alternatives/paravirt > patching that was discussed here [1] and here [2]. To briefly summarize the > bug, patch modules that contained .altinstructions or .parainstructions > sections would break because these alternative/paravirt patches would be > applied first by the module loader (see x86 module_finalize()), then > livepatch would later clobber these patches when applying per-object > relocations. This lead to crashes and unpredictable behavior. > > One conclusion we reached from our last discussion was that we will > need to introduce some arch-specific code to address this problem. > This patchset presents a possible fix for the bug by adding a new > arch-specific arch_klp_init_object_loaded() function that by default > does nothing but can be overridden by different arches. > > To fix this issue for x86, since we can access a patch module's Elf > sections through mod->klp_info, we can simply delay the calls to > apply_paravirt() and apply_alternatives() to arch_klp_init_object_loaded(), > which is called after relocations have been written for an object. > In addition, for patch modules, .parainstructions and .altinstructions are > prefixed by ".klp.arch.${objname}" so that the module loader ignores them > and livepatch can apply them manually. The solution looks correct to me. The fun will be how to generate the sections. If I get this correctly, it is not enough to rename the existing ones. Instead, we need to split .parainstructions and .altinstructions sections into per-object ones. I wonder if there is a plan for this. Especially I am interested into the patches created from sources ;-) I wonder if we could add a tag somewhere and improve the build infrastructure. Best Regards, Petr
Powered by blists - more mailing lists