From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753577AbcGGXwG (ORCPT ); Thu, 7 Jul 2016 19:52:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33671 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753028AbcGGXv5 (ORCPT ); Thu, 7 Jul 2016 19:51:57 -0400 Date: Thu, 7 Jul 2016 19:51:52 -0400 From: Jessica Yu To: Petr Mladek Cc: Josh Poimboeuf , Miroslav Benes , Jiri Kosina , Chris J Arges , Eugene Shatokhin , live-patching@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: Fix issue with alternatives/paravirt patches Message-ID: <20160707235152.GC9954@packer-debian-8-amd64.digitalocean.com> References: <1467772500-26092-1-git-send-email-jeyu@redhat.com> <20160707155633.GC3556@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160707155633.GC3556@pathway.suse.cz> X-OS: Linux eisen.io 3.16.0-4-amd64 x86_64 User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 07 Jul 2016 23:51:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ Petr Mladek [07/07/16 17:56 +0200]: >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. Hi Petr, That is correct, this means .parainstructions and .altinstructions will be split per-object and follow a similar naming scheme to the existing .klp.rela.${objname} sections. Then, we can apply these sections per-object with apply_alternatives() and apply_paravirt(). >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. I currently have a working branch of the kpatch-build tools that generates these sections. I'm hoping to get the code up in some shape or form soon; I'll post an update when it's up. Jessica