From: Torsten Duwe <duwe@lst.de>
To: Jiri Kosina <jikos@kernel.org>
Cc: Petr Mladek <pmladek@suse.com>,
Balbir Singh <bsingharora@gmail.com>,
linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
rostedt@goodmis.org, kamalesh@linux.vnet.ibm.com,
jeyu@redhat.com, live-patching@vger.kernel.org, mbenes@suse.cz
Subject: Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc
Date: Wed, 9 Mar 2016 12:16:47 +0100 [thread overview]
Message-ID: <20160309111647.GA27913@lst.de> (raw)
In-Reply-To: <alpine.LNX.2.00.1603091110510.3656@cbobk.fhfr.pm>
On Wed, Mar 09, 2016 at 11:13:05AM +0100, Jiri Kosina wrote:
> On Wed, 9 Mar 2016, Torsten Duwe wrote:
> > was my first choice. Arguments on the stack? I thought we'll deal with them
> > once we get there (e.g. _really_ need to patch a varargs function or one
> > with a silly signature).
>
> Well, the problem is, once such need arises, it's too late already.
No, not if it's documented.
> You need to be able to patch the kernels which are already out there,
> running on machines potentially for ages once all of a sudden there is a
> CVE for >8args / varargs function.
Then you'd need a solution like I sent out yesterday, with a pre-prologue
caller that pops the extra frame, so the replacement can be more straight-
forward. Or you can just deal with the shifted offsets in the replacement.
I'll try to demonstrate the alternative. That would then be required for
_all_ replacement functions. Or can the live patching framework differentiate
and tell ftrace_caller whether to place a stack frame or not?
Miroslav? Petr? Can we have 2 sorts of replacement functions?
Torsten
next prev parent reply other threads:[~2016-03-09 11:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 6:59 [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc Balbir Singh
2016-03-09 9:19 ` Torsten Duwe
2016-03-09 9:44 ` Petr Mladek
2016-03-09 10:03 ` Torsten Duwe
2016-03-09 10:13 ` Jiri Kosina
2016-03-09 11:16 ` Torsten Duwe [this message]
2016-03-09 12:56 ` Petr Mladek
2016-03-09 10:27 ` Michael Ellerman
2016-03-10 0:40 ` Balbir Singh
2016-03-15 10:25 ` Miroslav Benes
2016-03-17 15:42 ` Torsten Duwe
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=20160309111647.GA27913@lst.de \
--to=duwe@lst.de \
--cc=bsingharora@gmail.com \
--cc=jeyu@redhat.com \
--cc=jikos@kernel.org \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.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.