public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Jeff Dike <jdike@karaya.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] Allow UML kernel to run in a separate host address space
Date: Sat, 28 Dec 2002 19:59:13 -0500	[thread overview]
Message-ID: <20021229005913.GA25970@nevyn.them.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0212281227510.25566-100000@home.transmeta.com>

On Sat, Dec 28, 2002 at 12:50:53PM -0800, Linus Torvalds wrote:
> 
> On Sat, 28 Dec 2002, Jeff Dike wrote:
> > 
> > > What are the semantics the host code wants/needs, 
> > 
> > 1 - Multiple address spaces per process
> > 2 - Ability to make a child switch between address spaces
> > 3 - Ability to manipulate a child's address space (i.e. mmap, munmap, mprotect
> >     on an address space which is not current->mm)
> 
> Well, #3 falls under "ptrace()" as far as I'm concerned, I don't really 
> want to expose things through /proc (or /dev, which is even _worse_).
> 
> We used to have things that could be done with /proc/<pid>/mem, and it was 
> a total security disaster. It was removed in the 2.3.x series because of 
> that.

FWIW, GDB also would like to have #3.  We can do without it; GDB
already supports calling functions in the inferior by a stack or code
trampoline, so we could just make the child call mprotect; but it would
be faster and simpler to have a ptrace op for it.  HP/UX had, among
other things, TT_PROC_SET_MPROTECT and TT_PROC_GET_MPROTECT; I don't
think we have a system call equivalent to GET_MPROTECT right now.

Of course, without more comprehensive kernel support doing
protection-based watchpoints this way is murder for perfomance, almost
as bad as just doing it by single-stepping.  You need to disable them
at every syscall entry, which means that you can't have multiple
threads running in userspace while one thread is in a syscall, or you
might miss a watchpoint event.

It would be ideal to have some way to set the permissions such that
accesses from inside the kernel succeeded and from userspace failed
(i.e. render it temporarily a kernel page; but not exactly; we'd want
things like "normally writeable; currently writeable by the kernel;
still currently readable by userspace" for a normal watchpoint).
I don't know if that's practical without impacting MM performance. 

Suggestions welcome; I haven't really started to work on this yet
although it's creeping up my list of important debugger projects. 
PowerPC MMUs have a mechanism that could be used for this but I don't
know if other architectures do.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  parent reply	other threads:[~2002-12-29  0:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-28 15:47 [PATCH] Allow UML kernel to run in a separate host address space Jeff Dike
2002-12-28 19:34 ` Linus Torvalds
2002-12-28 20:24   ` Jeff Dike
2002-12-28 20:50     ` Linus Torvalds
2002-12-28 23:37       ` Jeff Dike
2002-12-29  4:13         ` Linus Torvalds
2002-12-29  5:12           ` Jeff Dike
2002-12-29  0:59       ` Daniel Jacobowitz [this message]
2002-12-29  4:03     ` Jeremy Fitzhardinge
2002-12-29  5:12       ` Jeff Dike
  -- strict thread matches above, loose matches on Subject: below --
2002-12-17 23:24 Jeff Dike

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=20021229005913.GA25970@nevyn.them.org \
    --to=dan@debian.org \
    --cc=jdike@karaya.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@transmeta.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