mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@redhat.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Petr Mladek <pmladek@suse.com>, Jiri Kosina <jikos@kernel.org>,
	Chris J Arges <chris.j.arges@canonical.com>,
	Eugene Shatokhin <eugene.shatokhin@rosalab.ru>,
	live-patching@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Fix issue with alternatives/paravirt patches
Date: Thu, 21 Jul 2016 01:10:30 -0400	[thread overview]
Message-ID: <20160721051029.GA20262@packer-debian-8-amd64.digitalocean.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1607121400010.16277@pobox.suse.cz>

+++ Miroslav Benes [12/07/16 14:06 +0200]:
>On Tue, 5 Jul 2016, 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.
>>
>> Currently for kpatch, we don't support including jump table sections in
>> the patch module, and supporting .smp_locks is currently broken, so we
>> don't consider those sections (for now).
>>
>> I did some light testing with some patches to kvm and verified that the
>> original issue reported in [2] was fixed.
>>
>> Based on linux-next.
>>
>> [1] http://thread.gmane.org/gmane.linux.kernel/2185604/
>> [2] https://github.com/dynup/kpatch/issues/580
>>
>> Jessica Yu (2):
>>   livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks
>>   livepatch/x86: apply alternatives and paravirt patches after relocations
>>
>>  arch/x86/kernel/Makefile    |  1 +
>>  arch/x86/kernel/livepatch.c | 66 +++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/livepatch.h   |  3 +++
>>  kernel/livepatch/core.c     | 12 +++++++--
>>  4 files changed, 80 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/x86/kernel/livepatch.c
>
>Hi,
>
>thanks Jessica for implementing it. It does not look as bad as I was
>afraid, which is great. Few remarks...
>
>Is there a problem when you need to generate a dynrela for paravirt code?
>I mean one does not know during the build of a patch module if paravirt
>would or would not be applied. If such code needs to be relocated it could
>be a problem for kpatch-build. Is this correct or am I missing something?

In kpatch-build, "special" sections like .parainstructions and
.altinstructions are into consideration. These sections are included
in the final patch module if they reference any of the new replacement
code. Like with any other section, kpatch-build will convert any relas
from .rela.parainstructions (for example) to dynrelas if it is
necessary.  And with this patch we apply all "dynrelas" (which are now
actual relas in .klp.rela sections) first before applying any
paravirt/alternatives patches in arch_klp_init_object_loaded(), which
is the correct order.

>Now the other architectures we support. s390 should be ok. There is
>nothing much in module_finalize() there. powerpc is different though. It
>is quite similar to x86_64 case. And also arm64 needs to be handled in
>future.

Yeah, I think we are OK for s390, arm64 looks fairly straightforward
(just a call to apply_alternatives()), powerpc looks slightly more
involved but I haven't thoroughly dug into it yet.

So other arches will need to have arch_klp_init_object_loaded()
implemented eventually (if needed), but I think it is fine for now to
fix this issue on x86 first, since that's where the original bug
cropped up.

Jessica

  reply	other threads:[~2016-07-21  5:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-06  2:34 [PATCH 0/2] " Jessica Yu
2016-07-06  2:34 ` [PATCH 1/2] livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks Jessica Yu
2016-07-06  2:35 ` [PATCH 2/2] livepatch/x86: apply alternatives and paravirt patches after relocations Jessica Yu
2016-07-08 15:44   ` Josh Poimboeuf
2016-07-07 15:56 ` [PATCH 0/2] Fix issue with alternatives/paravirt patches Petr Mladek
2016-07-07 22:53   ` Josh Poimboeuf
2016-07-12 11:55     ` Miroslav Benes
2016-07-12 14:01       ` Josh Poimboeuf
2016-07-13  1:18         ` Jessica Yu
2016-07-07 23:51   ` Jessica Yu
2016-07-08  5:22 ` [PATCH 0/2] " Christopher Arges
2016-07-08 16:57   ` Jessica Yu
2016-07-12 12:06 ` [PATCH 0/2] " Miroslav Benes
2016-07-21  5:10   ` Jessica Yu [this message]
2016-07-21  8:48     ` Miroslav Benes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160721051029.GA20262@packer-debian-8-amd64.digitalocean.com \
    --to=jeyu@redhat.com \
    --cc=chris.j.arges@canonical.com \
    --cc=eugene.shatokhin@rosalab.ru \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=pmladek@suse.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®