public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Takashi Ikebe <ikebe.takashi@lab.ntt.co.jp>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Date: Sat, 23 Apr 2005 18:17:27 +0200	[thread overview]
Message-ID: <m1y8b9xyaw.fsf@muc.de> (raw)
In-Reply-To: <4263275A.2020405@lab.ntt.co.jp> (Takashi Ikebe's message of "Mon, 18 Apr 2005 12:19:54 +0900")

Takashi Ikebe <ikebe.takashi@lab.ntt.co.jp> writes:

> The patch was over 50k, so I separate it to each architecture and in line..
>
> This patch add function called "Live patching" which is defined on
> OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 kernel.
> The live patching allows process to patch on-line (without restarting
> process) on i386 and x86_64 architectures, by overwriting jump assembly
> code on entry point of functions which you want to fix, to patched
> functions.

How exactly is this different from ptrace?
Seems just like a ptrace memcpy extension 
Is the patching really that time critical that you cant do it 
with normal ptrace?


> +	if(((current->uid != tsk->euid) ||
> +	    (current->uid != tsk->suid) ||
> +	    (current->uid != tsk->uid) ||
> +	    (current->gid != tsk->egid) ||
> +	    (current->gid != tsk->sgid) ||
> +	    (current->gid != tsk->gid)) && !capable(CAP_SYS_PANNUS)) {
> +                // invalid user in sys_accesspvm
> +                return -EPERM;
> +        }
> +> +	p = vmalloc(len);

This needs a limit. 
annus-x86_64/arch/x86_64/kernel/entry.S
> --- linux-2.6.11.7-vanilla/arch/x86_64/kernel/entry.S	2005-04-08 03:57:30.000000000 +0900
> +++ linux-2.6.11.7-pannus-x86_64/arch/x86_64/kernel/entry.S	2005-04-18 10:45:47.000000000 +0900
> @@ -214,6 +214,8 @@ sysret_check:		
>  	/* Handle reschedules */
>  	/* edx:	work, edi: workmask */	
>  sysret_careful:
> +	cmpl $0,threadinfo_inipending(%rcx)
> +	jne sysret_init

Put the check into the normal notify_resume work mask, not adding
a separate check into this critical fast path.

>  	CFI_ENDPROC
>  
>  /* 
> + * In the case restorer calls rt_handlereturn, collect and store registers,
> + * and call rt_handlereturn with stored register struct.
> + */
> +ENTRY(stub_rt_handlereturn)

This seems quite pointless since ptrace and can change all registers
in a child.

Didnt review more.

-Andi

  parent reply	other threads:[~2005-04-23 16:17 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-18  3:19 [PATCH x86_64] Live Patching Function on 2.6.11.7 Takashi Ikebe
2005-04-18  4:07 ` Chris Wedgwood
2005-04-18  4:19   ` Takashi Ikebe
2005-04-18  4:42     ` Daniel Jacobowitz
2005-04-18  4:55       ` Nicholas Miell
2005-04-18  5:01         ` Davide Libenzi
2005-04-18  5:41           ` Takashi Ikebe
2005-07-11  7:18           ` [PATCH] eventpoll : Suppress a short lived lock from struct file Eric Dumazet
2005-07-11  8:34             ` Peter Zijlstra
2005-07-11  9:29               ` Eric Dumazet
2005-07-11 14:00                 ` Davide Libenzi
2005-07-11 15:20                   ` Eric Dumazet
2005-04-18  5:00       ` [PATCH x86_64] Live Patching Function on 2.6.11.7 David S. Miller
2005-04-18  6:12     ` Chris Wedgwood
2005-04-18  6:35       ` Chris Friesen
2005-04-18  6:48         ` Chris Wedgwood
2005-04-18 10:03         ` James Courtier-Dutton
2005-04-18  9:10           ` Chris Wedgwood
2005-04-18  7:32       ` Takashi Ikebe
2005-04-18  7:56         ` Chris Wedgwood
2005-04-18  8:37           ` Takashi Ikebe
2005-04-18  8:59             ` Chris Wedgwood
2005-04-18  9:16           ` Paul Jackson
2005-04-18  9:25             ` Chris Wedgwood
2005-04-18 11:30               ` Rik van Riel
2005-04-18 12:52                 ` Takashi Ikebe
2005-04-18 14:06                   ` Rik van Riel
2005-04-19  2:14                     ` Takashi Ikebe
2005-04-19  4:27                       ` Chris Wedgwood
2005-04-19  5:19                         ` Takashi Ikebe
2005-04-19  5:52                           ` Chris Wedgwood
2005-04-20  4:18                             ` Takashi Ikebe
2005-04-20  5:43                               ` Chris Wedgwood
2005-04-20  7:35                                 ` Takashi Ikebe
2005-04-20  7:50                                   ` Chris Wedgwood
2005-04-20  7:57                                     ` Takashi Ikebe
2005-04-20  8:26                                       ` Chris Wedgwood
2005-04-20  8:45                                         ` Takashi Ikebe
2005-04-20  8:51                                           ` Chris Wedgwood
2005-04-20 11:19                                           ` Rik van Riel
2005-04-20 15:06                                             ` Chris Friesen
2005-04-20  8:34                                       ` Miquel van Smoorenburg
2005-04-19  5:57                           ` Takashi Ikebe
2005-04-18 14:28               ` Paul Jackson
2005-04-20 13:10               ` Ralf Baechle
2005-04-20 15:08                 ` Chris Friesen
2005-04-23 16:17 ` Andi Kleen [this message]
2005-04-25  2:11   ` Takashi Ikebe
2005-04-25  2:48     ` Kyle Moffett
2005-04-25 10:39       ` Takashi Ikebe
2005-04-25 11:15         ` Kyle Moffett
2005-04-25 15:09         ` Pavel Machek
2005-04-25 15:54         ` Andi Kleen
2005-04-25 16:36         ` Valdis.Kletnieks
2005-04-26  1:34           ` Takashi Ikebe
2005-04-26  2:15             ` Kyle Moffett
2005-04-26  9:36             ` Pavel Machek
2005-04-26 13:05             ` Andi Kleen
     [not found] <3Uv7B-5lv-7@gated-at.bofh.it>
     [not found] ` <3UvKd-5RT-1@gated-at.bofh.it>
     [not found]   ` <3Uw3y-65a-1@gated-at.bofh.it>
     [not found]     ` <3UwmX-6gm-5@gated-at.bofh.it>
     [not found]       ` <3UwwG-6lY-7@gated-at.bofh.it>
     [not found]         ` <3UwGk-6Cv-9@gated-at.bofh.it>
     [not found]           ` <3Uxj2-6YL-1@gated-at.bofh.it>
2005-04-18 10:59             ` Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>

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=m1y8b9xyaw.fsf@muc.de \
    --to=ak@muc.de \
    --cc=ikebe.takashi@lab.ntt.co.jp \
    --cc=linux-kernel@vger.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