[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1196362612.6473.98.camel@perihelion>
Date: Thu, 29 Nov 2007 13:56:51 -0500
From: Jon Masters <jonathan@...masters.org>
To: Ray Lee <ray-lk@...rabbit.org>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>, tvrtko.ursulin@...hos.com,
Al Viro <viro@....linux.org.uk>,
Casey Schaufler <casey@...aufler-ca.com>,
Christoph Hellwig <hch@...radead.org>,
linux-kernel@...r.kernel.org, Valdis.Kletnieks@...edu
Subject: Re: Out of tree module using LSM
On Thu, 2007-11-29 at 10:40 -0800, Ray Lee wrote:
> On Nov 29, 2007 9:36 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > > closed. But more importantly further access to it can be blocked until
> > > appropriate actions are taken which also applies with your example, no? Is
> >
> > That bit is hard- very hard.
>
> In some sense it seems like the same problem faced by dynamic
> translators such as Qemu. They really want to vet a dirtied or faulted
> page before allowing the app to run unhindered. It's be nice to have
> some way to do that without virtualizing the whole of userspace.
Like I hinted at, you can't just "vet a page". Because a page alone is
meaningless garbage, unless it happens to be an extremely small program,
with headers, all nicely aligned. Most likely you don't know if a random
page of data is code from a COFF file, ELF file, or some random crap I
typed in at a terminal after having too much coffee.
So. You'd need to scan *all the pages* of *the entire file*, every time
that you performed any type of operation. Hence, that idea is completely
out right away. The on-access scanning isn't perfect, but it's probably
about as good as you can get and still have a reasonably usable system.
Jon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists