Re: Is ndo_do_ioctl still acceptable?

[Jason A. Donenfeld]

On Thu, Nov 12, 2015 at 9:30 PM, Austin S Hemmelgarn
 wrote:
>>
> On the other hand, based on what you are saying about your device, it sounds
> like you are working on some kind of cryptographically secured (either
> authenticated or encrypted or both) tunnel, in which case the fact that
> security is easier to handle with netlink than ioctls becomes important.  If
> you can't ensure security of the endpoint configuration, you can't ensure
> security of the tunnel itself.

Could you substantiate these claims that "security is easier to handle
with netlink". I've never heard this and I don't know why it'd be the
case. Are you referring to the fact that the copy_to/from_user dance
of ioctl opens up more potential vulnerabilities than netlink's
abstracted validation? Or something else? Just confused here...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is ndo_do_ioctl still acceptable?

[Austin S Hemmelgarn]

On 2015-11-12 11:58, Jason A. Donenfeld wrote:

Hi Stephen,

Thanks for your response.

On Thu, Nov 12, 2015 at 5:34 PM, Stephen Hemminger
 wrote:

The problem is ioctl's are device specific, and therefore create dependency
on the unique features supported by your device.
The question always comes up, why is this new API not something general?


In this case, it really is for unique features of my device. My device
has its own unique notion of a "peer" based on a particular elliptic
curve point and some other interesting things. It's not something
generalizable to other devices. The thing that makes my particular
device special is these attributes that I need to make configurable. I
think then, by your criteria, ioctl would actually be perfect. In
other words, I interpret what you wrote to mean "generalizable:
netlink. device-specific: ioctl." If that's a decent summary, then
ioctl is certainly good for me.

On the other hand, based on what you are saying about your device, it 
sounds like you are working on some kind of cryptographically secured 
(either authenticated or encrypted or both) tunnel, in which case the 
fact that security is easier to handle with netlink than ioctls becomes 
important.  If you can't ensure security of the endpoint configuration, 
you can't ensure security of the tunnel itself.





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Is ndo_do_ioctl still acceptable?

[Jason A. Donenfeld]

Hi Stephen,

Thanks for your response.

On Thu, Nov 12, 2015 at 5:34 PM, Stephen Hemminger
 wrote:
> The problem is ioctl's are device specific, and therefore create dependency
> on the unique features supported by your device.
> The question always comes up, why is this new API not something general?

In this case, it really is for unique features of my device. My device
has its own unique notion of a "peer" based on a particular elliptic
curve point and some other interesting things. It's not something
generalizable to other devices. The thing that makes my particular
device special is these attributes that I need to make configurable. I
think then, by your criteria, ioctl would actually be perfect. In
other words, I interpret what you wrote to mean "generalizable:
netlink. device-specific: ioctl." If that's a decent summary, then
ioctl is certainly good for me.

> And if you are dumping such a huge mound of information that only your driver
> could love, then why are you doing it? Is there anything in there that
> really matters?

There is. There's a nice userspace program used for configuring and
displaying the particular attributes of this device.

> If all you are really doing is dumping statistics then look at ethtool.

It's more than stats, unfortunately.

> If you are dealing with lots of virtual function devices, look how existing
> netlink info is trimmed.

Could you elaborate on this? What do you mean "trimmed"? And where do I look?

Regards,
Jason
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is ndo_do_ioctl still acceptable?

[Stephen Hemminger]

On Thu, 12 Nov 2015 05:59:03 +0100
"Jason A. Donenfeld"  wrote:

> Hi David & Folks,
> 
> Soon I will submit a virtual tunnel device driver to LKML for review.
> It uses rtnl_link_register to create a virtual network interface,
> which then handles encryption, authentication, and some other things,
> amongst various configured peers.
> 
> Right now the device is configurable via Netlink. It receives new
> peers and configuration via a rtnl_link_ops->changelink function, and
> it reports information back to userspace via a
> rtnl_link_ops->fill_info function.
> 
> Configuration works fine, though it is rather cumbersome to do this
> all via Netlink.
> 
> Reporting information back to userspace does not work fine. The reason
> is that sometimes there's too much information to report back to
> userspace than what can fit in a single preallocated Netlink skb. And
> since rtnl_link_ops->fill_info doesn't receive any information from
> userspace, I'm unable to use it to send back information in smaller
> pieces.
> 
> I realize I could register a whole new rtnl packet family and related
> set of functions with rtnl_register, such as what's done at the bottom
> of `net/core/rtnetlink.c`. This is extremely cumbersome and invasive
> though. It would require adding a new protocol family (like the
> already existing rtnl_register-ified functions for PF_UNSPEC and
> PF_BRIDGE), and I don't have enough clout to confidently submit a
> patch that augments `include/linux/socket.h` with a new PF/AF define.
> This seems very invasive and not appropriate for my driver.
> 
> What I'd really like to do is just implement ndo_do_ioctl. It seems to
> me that this gives me a precise interface to do exactly what I want in
> the cleanest and easiest to read possible way. I could have differing
> ioctls for differing things. I could write memory back to userspace in
> proper chunks, with the proper size. It's clear and straightforward
> how to do it, and what the completed result looks like. It doesn't
> require invasive changes into other parts of the kernel, as this would
> be self-contained. It's hard to imagine a better interface to use than
> ndo_do_ioctl.
> 
> But. But the word on the street is that kernel hipsters hate ioctls
> and espouse the use of netlink everywhere with religious fervor, and
> will burn at the stake any submissions I might send that go anywhere
> near using ndo_do_ioctl rather than (the most likely ill-fitting for
> the task) netlink. That, and the maintainers of the `ip` tool will be
> upset too (even though they do already make use of several ioctls
> instead of netlink). I'm told everybody will leer and jeer at me if I
> use ndo_do_ioctl instead of netlink.
> 
> Except ndo_do_ioctl is *so* perfectly fitting here for my use case!
> 
> So what's the verdict on this? Do these aforementioned kernel hipsters
> not really matter so much, and ndo_do_ioctl is actually perfectly
> fine? Or must I really affix netlink onto my forthcoming submission?

The problem is ioctl's are device specific, and therefore create dependency
on the unique features supported by your device.
Also doing security validation on ioctl's is much harder.

The question always comes up, why is this new API not something general?
And if you are dumping such a huge mound of information that only your driver
could love, then why are you doing it? Is there anything in there that
really matters? 

If all you are really doing is dumping statistics then look at ethtool.
If you are dealing with lots of virtual function devices, look how existing
netlink info is trimmed.

Don't overanalyze this.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is ndo_do_ioctl still acceptable?

[Stephen Hemminger]

On Thu, 12 Nov 2015 23:19:06 +0100
"Jason A. Donenfeld"  wrote:

> On Thu, Nov 12, 2015 at 9:30 PM, Austin S Hemmelgarn
>  wrote:
> >>
> > On the other hand, based on what you are saying about your device, it sounds
> > like you are working on some kind of cryptographically secured (either
> > authenticated or encrypted or both) tunnel, in which case the fact that
> > security is easier to handle with netlink than ioctls becomes important.  If
> > you can't ensure security of the endpoint configuration, you can't ensure
> > security of the tunnel itself.
> 
> Could you substantiate these claims that "security is easier to handle
> with netlink". I've never heard this and I don't know why it'd be the
> case. Are you referring to the fact that the copy_to/from_user dance
> of ioctl opens up more potential vulnerabilities than netlink's
> abstracted validation? Or something else? Just confused here...

It means that with netlink it possible to checks on field types and lengths
in generic manner. Ioctl's have the whole compat mess to deal with.
Also when using seccomp it is possible to write code to look at netlink
messages. With ioctl's that is much more difficult especially since the
same ioctl may have different meanings for each device type.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is ndo_do_ioctl still acceptable?

[Jason A. Donenfeld]

Hi David & Folks,

Soon I will submit a virtual tunnel device driver to LKML for review.
It uses rtnl_link_register to create a virtual network interface,
which then handles encryption, authentication, and some other things,
amongst various configured peers.

Right now the device is configurable via Netlink. It receives new
peers and configuration via a rtnl_link_ops->changelink function, and
it reports information back to userspace via a
rtnl_link_ops->fill_info function.

Configuration works fine, though it is rather cumbersome to do this
all via Netlink.

Reporting information back to userspace does not work fine. The reason
is that sometimes there's too much information to report back to
userspace than what can fit in a single preallocated Netlink skb. And
since rtnl_link_ops->fill_info doesn't receive any information from
userspace, I'm unable to use it to send back information in smaller
pieces.

I realize I could register a whole new rtnl packet family and related
set of functions with rtnl_register, such as what's done at the bottom
of `net/core/rtnetlink.c`. This is extremely cumbersome and invasive
though. It would require adding a new protocol family (like the
already existing rtnl_register-ified functions for PF_UNSPEC and
PF_BRIDGE), and I don't have enough clout to confidently submit a
patch that augments `include/linux/socket.h` with a new PF/AF define.
This seems very invasive and not appropriate for my driver.

What I'd really like to do is just implement ndo_do_ioctl. It seems to
me that this gives me a precise interface to do exactly what I want in
the cleanest and easiest to read possible way. I could have differing
ioctls for differing things. I could write memory back to userspace in
proper chunks, with the proper size. It's clear and straightforward
how to do it, and what the completed result looks like. It doesn't
require invasive changes into other parts of the kernel, as this would
be self-contained. It's hard to imagine a better interface to use than
ndo_do_ioctl.

But. But the word on the street is that kernel hipsters hate ioctls
and espouse the use of netlink everywhere with religious fervor, and
will burn at the stake any submissions I might send that go anywhere
near using ndo_do_ioctl rather than (the most likely ill-fitting for
the task) netlink. That, and the maintainers of the `ip` tool will be
upset too (even though they do already make use of several ioctls
instead of netlink). I'm told everybody will leer and jeer at me if I
use ndo_do_ioctl instead of netlink.

Except ndo_do_ioctl is *so* perfectly fitting here for my use case!

So what's the verdict on this? Do these aforementioned kernel hipsters
not really matter so much, and ndo_do_ioctl is actually perfectly
fine? Or must I really affix netlink onto my forthcoming submission?

Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html