Re: TALPA - a threat model? well sorta.

[Arjan van de Ven <arjan@infradead.org>]

On Thu, 14 Aug 2008 10:12:13 -0400
Eric Paris <eparis@redhat.com> wrote:

> On Wed, 2008-08-13 at 14:39 -0700, Arjan van de Ven wrote:
> > On Wed, 13 Aug 2008 14:57:44 -0400
> > Eric Paris <eparis@redhat.com> 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.
> 
> I've been thinking about this more over night.  I really like the idea
> for perf reasons but I'm scared of programs not expecting and thus
> poorly handling -EACCESS from read.  Every program ever is going to
> expect that back from open, but once you have the fd open its not
> common.  

you could stretch things and report -EIO.

> 
> The idea of multiple concurrent outstanding async notifications is
> going to be much more difficult to code, but hey, who am I to

well... do you really need a response?
you could just write it to a netlink socket...

> complain.  We could have outstanding async scanning requests for any
> number of writes, any number of closes, and any number of opens all
> at the same time.  The current interface believes that every request
> out requires a response but this type of interface basically requires
> some sort of coalescing.

or fire-and-forget.
> 
> Would you be opposed to a first patch round that did blocking
> enforcement on open like we have today and do sync scanning (blocking
> or return EWOULDBLOCK) on read if needed due to concurrent writes?

I think we need to sort the interface issue on this for sure, and
probably from the start...

> 


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org