From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Jessica Yu <jeyu@kernel.org>,
linux-s390@vger.kernel.org, heiko.carstens@de.ibm.com,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>
Subject: Re: [PATCH v2 6/9] s390/module: Use s390_kernel_write() for late relocations
Date: Wed, 22 Apr 2020 16:40:37 +0200 [thread overview]
Message-ID: <20200422164037.7edd21ea@thinkpad> (raw)
In-Reply-To: <18266eb2c2c9a2ce0033426837d89dcb363a85d3.1587131959.git.jpoimboe@redhat.com>
On Fri, 17 Apr 2020 09:04:31 -0500
Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> From: Peter Zijlstra <peterz@infradead.org>
>
> Because of late module patching, a livepatch module needs to be able to
> apply some of its relocations well after it has been loaded. Instead of
> playing games with module_{dis,en}able_ro(), use existing text poking
> mechanisms to apply relocations after module loading.
>
> So far only x86, s390 and Power have HAVE_LIVEPATCH but only the first
> two also have STRICT_MODULE_RWX.
>
> This will allow removal of the last module_disable_ro() usage in
> livepatch. The ultimate goal is to completely disallow making
> executable mappings writable.
>
> Also, for the late patching case, use text_mutex, which is supposed to
> be held for all runtime text patching operations.
>
> [ jpoimboe: Split up patches. Use mod state to determine whether
> memcpy() can be used. Add text_mutex. Make it build. ]
>
> Cc: linux-s390@vger.kernel.org
> Cc: heiko.carstens@de.ibm.com
> Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
> arch/s390/kernel/module.c | 125 ++++++++++++++++++++++++--------------
> 1 file changed, 79 insertions(+), 46 deletions(-)
Sorry, just noticed this. Heiko will return next month, and I'm not
really familiar with s390 livepatching. Adding Vasily, he might
have some more insight.
So, I might be completely wrong here, but using s390_kernel_write()
for writing to anything other than 1:1 mapped kernel, should go
horribly wrong, as that runs w/o DAT. It would allow to bypass
DAT write protection, which I assume is why you want to use it,
but it should not work on module text section, as that would be
in vmalloc space and not 1:1 mapped kernel memory.
Not quite sure how to test / trigger this, did this really work for
you on s390?
Regards,
Gerald
next prev parent reply other threads:[~2020-04-22 14:40 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 14:04 [PATCH v2 0/9] livepatch,module: Remove .klp.arch and module_disable_ro() Josh Poimboeuf
2020-04-17 14:04 ` [PATCH v2 1/9] livepatch: Disallow vmlinux.ko Josh Poimboeuf
2020-04-17 14:04 ` [PATCH v2 2/9] livepatch: Apply vmlinux-specific KLP relocations early Josh Poimboeuf
2020-04-20 17:57 ` Joe Lawrence
2020-04-20 18:25 ` Josh Poimboeuf
2020-04-20 19:01 ` Joe Lawrence
2020-04-20 19:11 ` Josh Poimboeuf
2020-04-20 19:49 ` Joe Lawrence
2020-04-20 19:51 ` Josh Poimboeuf
2020-04-23 1:10 ` Joe Lawrence
2020-04-21 11:54 ` Miroslav Benes
2020-04-17 14:04 ` [PATCH v2 3/9] livepatch: Remove .klp.arch Josh Poimboeuf
2020-04-17 14:04 ` [PATCH v2 4/9] livepatch: Prevent module-specific KLP rela sections from referencing vmlinux symbols Josh Poimboeuf
2020-04-17 14:04 ` [PATCH v2 5/9] s390: Change s390_kernel_write() return type to match memcpy() Josh Poimboeuf
2020-04-17 14:04 ` [PATCH v2 6/9] s390/module: Use s390_kernel_write() for late relocations Josh Poimboeuf
2020-04-22 12:28 ` Miroslav Benes
2020-04-24 13:43 ` Josh Poimboeuf
2020-04-22 14:40 ` Gerald Schaefer [this message]
2020-04-22 15:21 ` Gerald Schaefer
2020-04-22 19:46 ` Josh Poimboeuf
2020-04-23 12:33 ` Gerald Schaefer
2020-04-23 13:22 ` Miroslav Benes
2020-04-23 14:12 ` Josh Poimboeuf
2020-04-23 18:10 ` Josh Poimboeuf
2020-04-23 23:26 ` Josh Poimboeuf
2020-04-24 2:35 ` Joe Lawrence
2020-04-24 4:12 ` Josh Poimboeuf
2020-04-24 7:20 ` Christian Borntraeger
2020-04-24 13:37 ` Josh Poimboeuf
2020-04-30 14:38 ` Joe Lawrence
2020-04-30 16:48 ` Josh Poimboeuf
2020-04-30 17:04 ` Joe Lawrence
2020-04-23 14:21 ` Joe Lawrence
2020-04-17 14:04 ` [PATCH v2 7/9] x86/module: Use text_poke() " Josh Poimboeuf
2020-04-17 14:29 ` Peter Zijlstra
2020-04-17 14:51 ` Josh Poimboeuf
2020-04-17 14:04 ` [PATCH v2 8/9] livepatch: Remove module_disable_ro() usage Josh Poimboeuf
2020-04-17 14:04 ` [PATCH v2 9/9] module: Remove module_disable_ro() Josh Poimboeuf
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=20200422164037.7edd21ea@thinkpad \
--to=gerald.schaefer@de.ibm.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jeyu@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.