mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: jikos@kernel.org, jpoimboe@redhat.com, jeyu@kernel.org
Cc: pmladek@suse.com, live-patching@vger.kernel.org,
	linux-kernel@vger.kernel.org, Miroslav Benes <mbenes@suse.cz>
Subject: [PATCH 0/3] Deny the patched modules to be removed
Date: Thu,  7 Jun 2018 11:29:46 +0200	[thread overview]
Message-ID: <20180607092949.1706-1-mbenes@suse.cz> (raw)

Quoting the second patch's changelog:

    Josh reported a bug:
    
      When the object to be patched is a module, and that module is
      rmmod'ed and reloaded, it fails to load with:
    
      module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 2, loc 00000000ba0302e9, val ffffffffa03e293c
      livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' (-8)
      livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to load module 'nfsd'
    
      The livepatch module has a relocation which references a symbol
      in the _previous_ loading of nfsd. When apply_relocate_add()
      tries to replace the old relocation with a new one, it sees that
      the previous one is nonzero and it errors out.
    
      On ppc64le, we have a similar issue:
    
      module_64: livepatch_nfsd: Expected nop after call, got e8410018 at e_show+0x60/0x548 [livepatch_nfsd]
      livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' (-8)
      livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to load module 'nfsd'
    
    He also proposed three different solutions. We could remove the error
    check in apply_relocate_add() introduced by commit eda9cec4c9a1
    ("x86/module: Detect and skip invalid relocations"). However the check
    is useful for detecting corrupted modules.
    
    We could also reverse the relocation patching (clear all relocation
    targets on x86_64, or return back nops on powerpc) in
    klp_unpatch_object(). The solution is not universal and is too much
    arch-specific.
    
    We decided to deny the patched modules to be removed. If it proves to be
    a major drawback for users, we can still implement a different approach.

There were many subtle details to check, so it may be broken somewhere.
Hopefully it is not, but please review carefully.

Miroslav Benes (3):
  livepatch: Nullify obj->mod in klp_module_coming()'s error path
  livepatch: Deny the patched modules to be removed
  module: Remove superfluous call to klp_module_going()

 kernel/livepatch/core.c | 25 +++++++++++++++++++++++--
 kernel/module.c         |  1 -
 2 files changed, 23 insertions(+), 3 deletions(-)

-- 
2.17.0

             reply	other threads:[~2018-06-07  9:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07  9:29 Miroslav Benes [this message]
2018-06-07  9:29 ` [PATCH 1/3] livepatch: Nullify obj->mod in klp_module_coming()'s error path Miroslav Benes
2018-06-11  9:03   ` Petr Mladek
2018-06-07  9:29 ` [PATCH 2/3] livepatch: Deny the patched modules to be removed Miroslav Benes
2018-06-11 11:41   ` Petr Mladek
2018-06-11 12:43     ` Miroslav Benes
2018-06-07  9:29 ` [PATCH 3/3] module: Remove superfluous call to klp_module_going() Miroslav Benes
2018-06-11  9:38   ` Jessica Yu

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=20180607092949.1706-1-mbenes@suse.cz \
    --to=mbenes@suse.cz \
    --cc=jeyu@kernel.org \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=pmladek@suse.com \
    /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®