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
next prev 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