Re: [malware-list] TALPA - a threat model? well sorta.

[Eric Paris]

On Thu, 2008-08-14 at 09:24 -0400, Theodore Tso wrote:
> On Thu, Aug 14, 2008 at 10:30:56AM +0100, tvrtko.ursulin@xxxxxxxxxx wrote:
> > The thing is the idea never was for clean-dirty "database" to be 
> > persistent but to have the same lifetime as the inode (in memory one). And 
> > once the cache/database gets invalidated re-scanning happens on-demand so 
> > the 5TB problem does not exist. Concerns about multiple clients where 
> > every has a different versioning scheme are also not relevant with the 
> > proposed versioning scheme (see my reply to Arjan).
> 
> So in essence, what I hear you saying is that all AV products want to
> work in a mode where the moment the inode falls out of the inode
> cache, and we lose the "clean" bit, when the inode is brought back
> into the cache, it will be scanned again.  That is, the "clean" bit is
> never persistent, and never needs to be stored in memory.

There needs to be a way to say that an inode in cache needs to be
rescanned.  3 states this flag can be.  Clean, Dirty, Infected.  The
current talpa solution involves a global monotomically increasing
counter every time you change virus defs or make some "interesting"
change.  If global == inode flag we are clean.  If global == negative
inode flag we are infected.  if global > inode flag we are dirty and
need a scan.

> That seems fair; if it turns out there is an AV product that wants to
> optimize this a bit further, as long as we provide a persistent inode
> version/generation number, they can always do their own persistent
> database in userspace.

exporting i_version might be useful for better userspace caching,
although I've yet to see any reasonable description of how a userspace
database can map between data on disk and what they have in userspace.
How can a userspace process, given 2 file descriptors know they are
actually the same thing on disk?

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