public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Andi Kleen <ak@suse.de>
Cc: virtualization@lists.osdl.org, Andrew Morton <akpm@osdl.org>,
	Chris Wright <chrisw@osdl.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	Martin Bligh <mbligh@mbligh.org>,
	Pratap Subrahmanyam <pratap@vmware.com>,
	Christopher Li <chrisl@vmware.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Ingo Molnar <mingo@elte.hu>,
	prasanna@in.ibm.com, ananth@in.ibm.com,
	anil.s.keshavamurthy@intel.com, davem@davemloft.net
Subject: Re: [PATCH 19/21] i386 Kprobes semaphore fix
Date: Wed, 09 Nov 2005 08:46:53 -0800	[thread overview]
Message-ID: <437227FD.6040905@vmware.com> (raw)
In-Reply-To: <200511091438.11848.ak@suse.de>

Andi Kleen wrote:

>On Tuesday 08 November 2005 14:36, Zachary Amsden wrote:
>
>  
>
>>One can imagine clever uses for ptrace to do, say user space
>>virtualization (since I'm on the topic), or other neat things.  So there
>>is nothing really wrong about having the fully correct EIP conversion
>>(and here we shouldn't need to worry about races causing some issues
>>with strict correctness, since there can be one external control thread).
>>    
>>
>
>Well, the code still scaries me a bit, but ok. x86-64 left at least one case 
>intentionally out.
>
>  
>
>>But were kprobes even inteneded for userspace?  There are races here
>>that are difficult to close without some heavy machinery, and I would
>>rather not put the machinery in place if simplifying the code is the
>>right answer.
>>    
>>
>
>I believe user space kprobes are being worked on by some IBM India folks yes.
>  
>

I'm convinced this is pointless.  What does it buy you over a ptrace 
based debugger?  Why would you want extra code running in the kernel 
that can be done perfectly well in userspace?

Let me stress that if you are running on modified segment state, you 
have no way to safely determine the virtual address on which you took an 
instruction trap (int3, general protection, etc..).  If you can't 
determine the virtual address safely, you can't back out your code patch 
to remove the breakpoint.  At this point, you can't execute the next 
instruction; you must wait for a _policy_ decision to be made.  Adding 
policy decisions like this to the kernel surely seems like a bad idea.  
If the fallback is to have a debugger running in userspace that has a 
user or script attached that can make the interactive decision, then why 
not solve the entire problem in userspace from the start?  It's a lot 
safer, it simplifies the kernel kprobes code a lot, and it leaves the 
debugger implementation free to do anything it chooses, as well as not 
locking the solution to a particular kernel.

Zach

  reply	other threads:[~2005-11-09 16:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-08  4:39 [PATCH 19/21] i386 Kprobes semaphore fix Zachary Amsden
2005-11-08 13:12 ` Andi Kleen
2005-11-08 13:36   ` Zachary Amsden
2005-11-09 13:38     ` Andi Kleen
2005-11-09 16:46       ` Zachary Amsden [this message]
2005-11-09 16:58         ` Ingo Molnar
2005-11-09 17:52           ` Zachary Amsden
2005-11-10 18:09             ` Prasanna S Panchamukhi
2005-11-10 14:58               ` Zachary Amsden
2005-11-10 16:16               ` H. Peter Anvin
2005-11-11 15:27             ` Andi Kleen
2005-11-11 15:25         ` Andi Kleen
2005-11-14  5:54           ` Prasanna S Panchamukhi
     [not found]     ` <20051109093755.GA10361@in.ibm.com>
2005-11-10 16:33       ` Prasanna S Panchamukhi
     [not found] <20051108074430.GG28201@elte.hu>
2005-11-08 13:26 ` Zachary Amsden

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=437227FD.6040905@vmware.com \
    --to=zach@vmware.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=chrisl@vmware.com \
    --cc=chrisw@osdl.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@mbligh.org \
    --cc=mingo@elte.hu \
    --cc=prasanna@in.ibm.com \
    --cc=pratap@vmware.com \
    --cc=torvalds@osdl.org \
    --cc=virtualization@lists.osdl.org \
    --cc=zwane@arm.linux.org.uk \
    /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