[FFmpeg-devel] [PATCH] NellyMoser audio decoder

[Rich Felker]

On Wed, Sep 12, 2007 at 12:02:18AM -0400, Daniel Serpell wrote:
> Hi
> 
> El Tue, Sep 11, 2007 at 08:02:32PM -0400, Rich Felker escribio:
> > On Wed, Sep 12, 2007 at 01:30:22AM +0200, Michael Niedermayer wrote:
> > > 
> > > the argument that the kernel can find such tables quickly even if 
> > > generated at runtime and share them with a copy on write hasnt been
> > > brought up yet :)
> > 
> > I don't want a kernel process hashing and comparing pages while I'm
> > trying to watch a movie to determine which ones it can combine... The
> > extra bookkeeping is just a bad idea.
> 
> But you could do it only on page-out. Just hash the page before going
> to disk. If the hash matches an already paged-out one, you don't have
> to store it again.

Nope. After comparing the hashes, you must read-in the paged-out page
and do a full comparison. Hash is not sufficient for comparison. Here,
a vulnerability against the hash would mean the ability to overwrite
arbitrary data owned by other processes and even users, which would be
disastrous.

Even without a vulnerability, you'll get a random collision given
enough time. Not likely on a single machine, but the likelihood that
some computer somewhere in the world would be affected by it within a
one-year period is probably nontrivial unless you make the hashes so
large that paging-out actually leaves a big hash in memory.

Thus, it's much smarter to do the comparison and page-consolidation
while both pages are still in memory, rather than after one of them
has already been paged out... I don't know if this can be made
efficient or not.

Rich