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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080814064656.13361901@infradead.org>
Date:	Thu, 14 Aug 2008 06:46:56 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	tvrtko.ursulin@...hos.com
Cc:	Eric Paris <eparis@...hat.com>, alan@...rguk.ukuu.org.uk,
	andi@...stfloor.org, hch@...radead.org,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	malware-list-bounces@...sg.printk.net, peterz@...radead.org,
	viro@...IV.linux.org.uk
Subject: Re: [malware-list] TALPA - a threat model?  well sorta.

On Thu, 14 Aug 2008 10:46:55 +0100
tvrtko.ursulin@...hos.com wrote:

> 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?

close isn't the answer just because you can write content to the file
after that (and that's not just theoretical, glibc stdio supports mmap
etc); "dirty" *has* to be the event anyway. It's not impossible to
solve; even say a 1 second rearming delay would avoid 99.9% of the
useless rescans while still making sure everything gets scanned at some
point. Anyway this kind of policy can be done in userspace (and you can
get really fancy there and offer the admin various policies)

> 
> > > 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. 

there's quite a few programs that open() but never read.
open+fstat is not uncommon as programming pattern for example;
with async-in-open (and then wait or sync in read) we wouldn't have the
big hit caused by the latency for the sync scan.
(I realize this pattern is much more likely to happen on posixy systems
than it is on windows.. one of those differences ;-)

-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/