From: tvrtko.ursulin@sophos.com
To: Eric Paris <eparis@redhat.com>
Cc: alan@lxorguk.ukuu.org.uk, andi@firstfloor.org,
Arjan van de Ven <arjan@infradead.org>,
hch@infradead.org, linux-kernel@vger.kernel.org,
malware-list@lists.printk.net,
malware-list-bounces@dmesg.printk.net, peterz@infradead.org,
viro@ZenIV.linux.org.uk
Subject: Re: [malware-list] TALPA - a threat model? well sorta.
Date: Thu, 14 Aug 2008 10:46:55 +0100 [thread overview]
Message-ID: <20080814094701.A65372FE89E@pmx1.sophos.com> (raw)
In-Reply-To: <1218653864.3540.109.camel@localhost.localdomain>
Eric Paris wrote on 13/08/2008 19:57:44:
> > It's clear from the protection model that you described that on 'read'
> > you want to wait until the scan is done before you give the data to
the
> > process asking for it... and that's totally reasonable: "Do not give
> > out bad data" is a very clear line in terms of security.
> >
> > for the "dirty" case it gets muddy. You clearly want to scan "some
> > time" after the write, from the principle of getting rid of malware
> > that's on the disk, but it's unclear if this HAS to be synchronous.
> > (obviously, synchronous behavior hurts performance bigtime so lets do
> > as little as we can of that without hurting the protection).
> > One advantage of doing the dirty case async (and a little time
delayed)
> > is that repeated writes will get lumped up into one scan in practice,
> > saving a ton of performance.
> > (scan-on-close is just another way of implementing "delay the dirty
> > scan").
> > Based on Alans comments, to me this sounds like we should have an
> > efficient mechanism to notify userspace of "dirty events"; this is not
> > virus scan specific in any way or form. And this mechanism likely will
> > need to allow multiple subscribers.
>
> I'm certainly willing to go down the inotify'ish path for async
> notification of 'dirty' inodes instead of implement my own async
> mechanism if I can find a way to do it.
Do I understand correctly that everyone agrees scanning whenever an inode
gets dirty would be a terrible thing for performance?
Another thing we have here is that malware could not be neccessariliy
identified until the very last write (one example where it will always be
the case are PDF files (I think)).
So the whole question is at which point should be performing an async
scan. Close seems like a natural point which should be ideal for majority
of applications, I don't see how any time-based lumping/delaying scheme
can be better than close?
> > for the open() case, I would argue that you don't need synchronous
> > behavior as long as the read() case is synchronous. I can imagine that
> > open() kicks off an async scan, and if it's done by the time the first
> > read() happens, no blocking at all happens.
>
> An interesting addition. Trying to keep these queues of events gets
> much more complex, but if people really think the open to read race is
> that important I've always said it wasn't impossible to close.
This really sounds pretty interesting. Not necessariliy so much as a
performance optimisation, because I am not sure there are so many programs
where first read comes long after the first open, but as closing the
open-read race.
Could the implementation be not so complicated after all? If we generated
the same (roughly) event on reads and pass it for scanning if cache has
been invalidated in the mean time? The only thing is this could be a big
performance hit so some benchmarking might be in order depending on which
the read hook could be made run-time optional.
--
Tvrtko A. Ursulin
Senior Software Engineer, Sophos
"Views and opinions expressed in this email are strictly those of the
author.
The contents has not been reviewed or approved by Sophos."
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
next prev parent reply other threads:[~2008-08-14 9:47 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-13 16:36 TALPA - a threat model? well sorta Eric Paris
2008-08-13 16:24 ` Alan Cox
2008-08-13 16:47 ` Eric Paris
2008-08-13 16:37 ` Alan Cox
2008-08-13 17:00 ` Eric Paris
2008-08-13 19:59 ` Alan Cox
2008-08-13 21:24 ` [malware-list] " Press, Jonathan
2008-08-13 21:13 ` Alan Cox
2008-08-13 21:35 ` Rik van Riel
2008-08-13 21:23 ` Alan Cox
2008-08-15 3:25 ` Eric Paris
2008-08-15 20:16 ` Jan Harkes
2008-08-15 22:05 ` Arjan van de Ven
2008-08-17 23:19 ` Eric Paris
2008-08-17 23:26 ` Arjan van de Ven
2008-08-17 21:11 ` David Collier-Brown
2008-08-18 15:33 ` Alan Cox
2008-08-18 16:43 ` Rik van Riel
[not found] ` <20080819071416.GA14731@elf.ucw.cz>
2008-08-19 16:10 ` HSM (was Re: [malware-list] TALPA - a threat model? well sorta.) Rik van Riel
2008-08-19 19:20 ` Pavel Machek
2008-08-19 20:33 ` Rik van Riel
2008-08-20 17:03 ` Pavel Machek
2008-08-13 17:07 ` TALPA - a threat model? well sorta Christoph Hellwig
2008-08-14 13:00 ` Arnd Bergmann
2008-08-13 16:57 ` Greg KH
2008-08-13 17:39 ` Arjan van de Ven
2008-08-13 18:15 ` Theodore Tso
2008-08-13 18:21 ` Arjan van de Ven
2008-08-14 9:18 ` tvrtko.ursulin
2008-08-13 19:02 ` Eric Paris
2008-08-13 19:29 ` Theodore Tso
2008-08-13 21:15 ` [malware-list] " Press, Jonathan
2008-08-14 9:30 ` tvrtko.ursulin
2008-08-14 12:03 ` Press, Jonathan
2008-08-14 12:27 ` tvrtko.ursulin
2008-08-15 14:31 ` Pavel Machek
2008-08-14 13:24 ` Theodore Tso
2008-08-14 13:48 ` Eric Paris
2008-08-14 15:50 ` Theodore Tso
2008-08-14 17:29 ` Eric Paris
2008-08-14 19:17 ` Theodore Tso
2008-08-14 19:20 ` Eric Paris
2008-08-14 19:34 ` Christoph Hellwig
2008-08-14 19:41 ` Theodore Tso
2008-08-14 20:20 ` Christoph Hellwig
2008-08-14 21:21 ` J. Bruce Fields
2008-08-14 23:34 ` Theodore Tso
2008-08-19 21:43 ` J. Bruce Fields
2008-08-15 1:44 ` david
2008-08-15 2:04 ` Theodore Tso
2008-08-15 3:41 ` Arjan van de Ven
2008-08-15 5:05 ` david
2008-08-15 5:12 ` Johannes Weiner
2008-08-15 5:28 ` david
2008-08-15 5:36 ` david
2008-08-15 4:48 ` david
2008-08-15 8:51 ` Alan Cox
2008-08-15 14:37 ` Pavel Machek
2008-08-13 18:57 ` Eric Paris
2008-08-13 21:39 ` Arjan van de Ven
2008-08-14 14:12 ` Eric Paris
2008-08-14 15:57 ` Arjan van de Ven
2008-08-15 10:07 ` Helge Hafting
2008-08-15 10:37 ` Peter Zijlstra
2008-08-15 13:10 ` [malware-list] " Press, Jonathan
2008-08-15 13:18 ` douglas.leeder
2008-08-15 17:04 ` Theodore Tso
2008-08-15 18:09 ` Press, Jonathan
2008-08-18 10:09 ` Helge Hafting
2008-08-18 10:14 ` Peter Zijlstra
2008-08-18 10:24 ` tvrtko.ursulin
2008-08-18 10:25 ` douglas.leeder
2008-08-15 16:25 ` david
2008-08-15 16:30 ` Press, Jonathan
2008-08-15 17:33 ` david
2008-08-15 17:40 ` Press, Jonathan
2008-08-15 17:47 ` david
2008-08-15 18:06 ` Valdis.Kletnieks
2008-08-15 20:05 ` david
2008-08-15 20:17 ` Theodore Tso
2008-08-15 18:17 ` Press, Jonathan
2008-08-15 20:08 ` david
2008-08-18 10:02 ` Helge Hafting
2008-08-15 10:44 ` tvrtko.ursulin
2008-08-14 9:46 ` tvrtko.ursulin [this message]
2008-08-14 13:46 ` [malware-list] " Arjan van de Ven
2008-08-15 1:37 ` david
2008-08-15 1:31 ` david
2008-08-15 16:06 ` Pavel Machek
2008-08-18 12:21 ` david
2008-08-18 13:30 ` Pavel Machek
2008-08-19 0:03 ` david
2008-08-13 18:17 ` Andi Kleen
2008-08-13 18:21 ` H. Peter Anvin
2008-08-13 18:24 ` Arjan van de Ven
2008-08-13 18:40 ` Eric Paris
2008-08-14 0:18 ` Mihai Donțu
2008-08-14 11:58 ` [malware-list] " Press, Jonathan
2008-08-14 12:34 ` Mihai Donțu
2008-08-14 0:14 ` 7v5w7go9ub0o
2008-08-14 2:25 ` 7v5w7go9ub0o
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=20080814094701.A65372FE89E@pmx1.sophos.com \
--to=tvrtko.ursulin@sophos.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=eparis@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=malware-list-bounces@dmesg.printk.net \
--cc=malware-list@lists.printk.net \
--cc=peterz@infradead.org \
--cc=viro@ZenIV.linux.org.uk \
/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).