[lkml]   [2008]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: TALPA - a threat model? well sorta.
On Wed, 13 Aug 2008 14:57:44 -0400
Eric Paris <> wrote:

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

it's not "just" about open-to-read race.
it's about open being non-blocking, and if read is not immediate, never
hitting the latency at all.

The real point is that "read" is the actual point you want to
intercept, not "open" (you even wrote that in your description).. so
why not just do that ?
The open case then is just a performance optimization.

> > Open questions now are
> > 4) do we have the kernel kick off an async scan in open() or do we
> > have glibc do this
> > 5) do we have the kernel do the sync scan on read/mmap/.. or do we
> > have glibc do this
> scan on mmap read? How do I implement this?

on calling mmap(); not at fault time.

If you want to reach me at my work email, use
For development, discussion and tips for power savings,

 \ /
  Last update: 2008-08-13 23:41    [W:0.169 / U:1.468 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site