Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker".

[Luis R. Rodriguez]

On Fri, Sep 24, 2004 at 10:30:04AM +0400, Evgeniy Polyakov wrote:
> On Fri, 2004-09-24 at 10:14, Evgeniy Polyakov wrote:
> > On Fri, 2004-09-24 at 09:48, Luis R. Rodriguez wrote:
> > > On Fri, Sep 24, 2004 at 07:40:32AM +0400, Evgeniy Polyakov wrote:
> > > > On Fri, 2004-09-24 at 01:54, Luis R. Rodriguez wrote:
> > > > > RFC: 
> > > > > 
> > > > > Can and should we work towards using this as interface for drivers that
> > > > > need callbacks from an external (closed source) library/HAL?
> > > > 
> > > > As I mentioned to Richard Jonson, it can be considered as
> > > > ioctl. ioctl-ng!
> > > > Unified interface (as ioctl) can be used for any type of modules.
> > > > It is just a bit extended ioctl :)
> > > > 
> > > > And _yes_, it can be used to turn on/off binary-only callbacks.
> > > > Remember pwc - closed part can register callback and open part can
> > > > send message, or even closed part can register notification when
> > > > open part registers itself and begin to "trash the kernel".
> > > > 
> > > > I understand that it is not right way to include it is into the kernel,
> > > > but I personally do not understand how it is different 
> > > > from just extended ioctl. It was designed to be usefull and convenient,
> > > > and it is.
> > > > 
> > > > BTW, any binary-only module can _itself_ create netlink socket
> > > > with input callback. And that is all - it will be absolutely
> > > > the same as above.
> > > > 
> > > > One may consider connector as yet-another-netlink-helper.
> > > > 
> > > 
> > > Eh. I'm just wondering if there's any *right* way of using binary
> > > callbacks on a linux driver so that it doesn't *taint* and possibly
> > > *trash it*, as you said. I was wondering if perhaps through the
> > > connector we could somehow protect the kernel of possibly ill-behaved callbacks.
> > > 
> > > Comments?
> > 
> > Yes, we can.
> > Connector itself has quite enough information about it's registrants.
> > 
> > For example if it is somehow not good module( for example without GPL in
> > it's license string) then connector can be extended to call it's
> > callback from thread or in jail. If it is of interest I will think of
> > some plugable mechanism for callback environment( probably provide
> > ->before_callback() and ->after_callback() methods from external policy
> > provider which may check callback data and/or confine callback execution
> > ? ).
> > 
> > We also may confine closed modules from being able to use event
> > notification. In this scenario with worned out pwc-closed/open,
> > situation will not differ from what we have now.
> 
> BTW, it can also restrict userspace event notification in following way:
> when someone sends a message to notify group A of
> registering/unregistering of device with id {x,y} then connector can
> check if this group A is registered through callback_register_gpl(it is
> not exist for now, but can be created as a copy of callback_register() )
> or not. If it is GPL - send notify, else - execute 
> "mail -s "shit happens" linux-kernel@xxxxxxxxxxxxxxx" 
> in the way /sbin/hotplug is called.
> BTW, this decision also can be obtained from external policy module.
> 
> As you may think connector in current implementation is quite powerful
> interface( if I will not praise it, who will? :) ), and somebody can
> make bad things a bit easier with it, but it is also very flexible and
> can be tuned to suit your needs.
> 
> I'm open for discussion :)

Kernel maintainers: 

What do you think? Can a driver which requires access to binary
callbacks be included as part of the stock kernel as GPL if Evgeniy's
Connector provides some sort of kernel "jail" for the callback
functionality? 

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

Attachment: pgp00000.pgp
Description: PGP signature