All of lore.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 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.