netdev - Re: [PATCH 1/1] [DCCP][QPOLICY]: Make information about qpolicies available to userspace

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: <200806022356.27743.tomasz@grobelny.oswiecenia.net>
Date:	Mon, 2 Jun 2008 23:56:27 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>
Cc:	acme@...hat.com, dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] [DCCP][QPOLICY]: Make information about qpolicies available to userspace

Dnia Monday 02 of June 2008, Gerrit Renker napisał:
> | > It was for this part that I looked at netlink. This goes into the
> | > direction of a new API or at least API extensions.
> |
> | We basically need a callback from code that can access struct sock...
> |
> | > (...)
> | > For per-socket statistics there is indeed a need for a notification
> | > mechanism. If a synchronous mechanism is sufficient, then something
> | > like the current CCID-3 getsockopt(DCCP_SOCKOPT_CCID_{RX,TX}_INFO) can
> | > be used.
> |
> | Synchronous mechanism is acceptable but callback (at least as an option)
> | would be way nicer.
>
> I have been looking around for alternatives - there are some
> very good solutions for such aspects in the SCTP subsystem.
>
> They implement the subscription of event notifications on a socket for
> all sorts of events.
>
> A socket option performs this subscription, notifications are then passed
> along with data (I think also without, have not dug deep enough into the
> sources), via recvmsg(). This is the inverse path to qpolicies: the
> ancillary data is passed via cmsg(3) wrappers to the user.
>
> To distinguish events from normal (ancillary) data, SCTP sets the
> flag fields to MSG_NOTIFICATION.
>
> There are two good papers on this (the second one is a bit older):
> http://www.bsdcan.org/2008/schedule/events/91.en.html
> http://lwn.net/2001/features/OLS/pdf/pdf/sctp.pdf
>
> The sources are in net/sctp, the lksctp project is hosted at
> http://sourceforge.net/projects/lksctp
>
> I think that this approach is elegant and has something to offer for
> DCCP as well. What do you think?
>
I also thought about such a solution but I didn't state it because I thought 
it is even more hackish than the one below. Mostly because it 
interleaves "real data" with events (and there is no logical connection 
between the two as opposed to sending scenario). But if it is used in SCTP 
then maybe the whole idea is not that bad...
Anyway, I'll have a look at the documents and at the SCTP implementation.

> | Ok, but if we are at hackish ideas what about this one: use dccp_ioctl to
> | wait on a mutex. If an event occurs we release mutex thus allowing
> | dccp_ioctl to finish execution and consequently informing user that
> | something interesting has just happened - what it exactly is would have
> | to be determined by other means.
>
> I am trying to think in terms of how much documentation this would need
> in order to explain to someone how to use it. It seems feasible, but to
> me a bit complicated.
>
The basic idea is the same as above. The difference is that it would overload 
ioctl, not recv. But maybe we should use recv. Not because it is in any way 
better but just because it is already used that way in SCTP and has a few 
documents describing the approach.
-- 
Regards,
Tomasz Grobelny
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html