linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Pengfei Hu <hpfei.cn@gmail.com>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
	akpm@linux-foundation.org, torvalds@linux-foundation.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: Using module private memory to simulate microkernel's memory protection
Date: Wed, 11 Feb 2009 16:23:42 +0100	[thread overview]
Message-ID: <20090211152342.GA16550@elte.hu> (raw)
In-Reply-To: <20090211145525.GB10525@elte.hu>


* Ingo Molnar <mingo@elte.hu> wrote:

> * Pengfei Hu <hpfei.cn@gmail.com> wrote:
> 
> > >
> > > Hm, are you aware of the kmemcheck project?
> > >
> > >        Ingo
> > >
> > 
> > Frankly, I only know this project's name. Just when I nearly finished
> > this patch, I browsed http://git.kernel.org/ first time. I am only a
> > beginner in Linux kernel. Maybe I should first discuss before write
> > code. But I think it is not too late.
> > 
> > Can you tell me more about this project? I realy appreciate it.
> 
> Sure:

More info: kmemcheck was written by Vegard Nossum (and released more than
a year ago) and it uses similar principles as your patch: it enforces
memory usage constraints via pagetable access bits.

More description about kmemcheck can be found in the following LWN article:

  http://lwn.net/Articles/260068/

I think your idea of limiting execution to individual modules could perhaps
be combined with kmemcheck. It's the same general principle.

The difference is that your patch calls back from the page fault handler and
modifies the monitored pte's to present, brings in a TLB and then it modifies
it to not present. So the page can be accessed up until the TLB gets flushed.

Kmemcheck uses debug traps to execute a single instruction, and thus gets
finer grained control of what is visible to a task.

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-02-11 15:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10 13:42 Using module private memory to simulate microkernel's memory protection Pengfei Hu
2009-02-10 14:14 ` Ingo Molnar
2009-02-11 14:04   ` Pengfei Hu
2009-02-11 14:55     ` Ingo Molnar
2009-02-11 15:23       ` Ingo Molnar [this message]
2009-02-21  9:24         ` Pengfei Hu

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=20090211152342.GA16550@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=hpfei.cn@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vegard.nossum@gmail.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;
as well as URLs for NNTP newsgroup(s).