On Thu, 2007-11-29 at 11:11 -0800, Ray Lee wrote:
quoted text
> On Nov 29, 2007 10:56 AM, Jon Masters <jonathan@jonmasters.org> wrote:
> > On Thu, 2007-11-29 at 10:40 -0800, Ray Lee wrote:
> > > On Nov 29, 2007 9:36 AM, Alan Cox <alan@lxorguk.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.
> 
> *blink* Really?

Yeah, really.

quoted text
> To lift Alan's example, a naive first implementation
> would be to create a suffix tree of all of ESR's works, then scan each
> page on fault to see if there are any partial matches in the tree.

Ah, but I could write a sequence of pages that on their own looked
garbage, but in reality, when executed would print out a copy of the
Jargon File in all its glory. And if you still think you could look for
patterns, how about executable code that self-modifies in random ways
but when executed as a whole actually has the functionality of fetchmail
embedded within it? How would you guard against that?

Jon.


-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/