Re: tap(4) minor number too large
On Sun, Nov 11, 2018 at 10:03 PM David Gwynne wrote: ... > so like this? > ... > --- if_tun.c24 Feb 2018 07:20:04 - 1.181 > +++ if_tun.c12 Nov 2018 06:02:51 - > @@ -193,6 +193,9 @@ tun_create(struct if_clone *ifc, int uni > struct tun_softc*tp; > struct ifnet*ifp; > > + if (unit > minor(~0U)) > + return (ENXIO); > I would be inclined to write minor(~(dev_t)0) Just In Case, but ok either way.
Re: tap(4) minor number too large
On Sun, Nov 11, 2018 at 10:55:06PM -0700, Theo de Raadt wrote: > Philip Guenther wrote: > > > On Sun, Nov 11, 2018 at 9:45 PM David Gwynne wrote: > > > > > If you can trick someone into implementing 64bit device ids you can have > > > more than your 16 millionth tap device. > > > > > > > Hhahahahahahahhahahahahah. > > > > That would involve rolling six syscall numbers, not to mention handling the > > 64bit padding in one of mknod() or mknodat(). > > > > As the guy who did the last type bump that invasive, Just Say No. > > Right, it will never happen. It serves no purpose. > > The network driver can clamp itself at 24 bits, if it matters. yes, i just realised what greg was actually asking. so like this? Index: if_tun.c === RCS file: /cvs/src/sys/net/if_tun.c,v retrieving revision 1.181 diff -u -p -r1.181 if_tun.c --- if_tun.c24 Feb 2018 07:20:04 - 1.181 +++ if_tun.c12 Nov 2018 06:02:51 - @@ -193,6 +193,9 @@ tun_create(struct if_clone *ifc, int uni struct tun_softc*tp; struct ifnet*ifp; + if (unit > minor(~0U)) + return (ENXIO); + tp = malloc(sizeof(*tp), M_DEVBUF, M_WAITOK|M_ZERO); tp->tun_unit = unit; tp->tun_flags = TUN_INITED|TUN_STAYUP;
Re: tap(4) minor number too large
Philip Guenther wrote: > On Sun, Nov 11, 2018 at 9:45 PM David Gwynne wrote: > > > If you can trick someone into implementing 64bit device ids you can have > > more than your 16 millionth tap device. > > > > Hhahahahahahahhahahahahah. > > That would involve rolling six syscall numbers, not to mention handling the > 64bit padding in one of mknod() or mknodat(). > > As the guy who did the last type bump that invasive, Just Say No. Right, it will never happen. It serves no purpose. The network driver can clamp itself at 24 bits, if it matters.
Re: tap(4) minor number too large
On Sun, Nov 11, 2018 at 9:45 PM David Gwynne wrote: > If you can trick someone into implementing 64bit device ids you can have > more than your 16 millionth tap device. > Hhahahahahahahhahahahahah. That would involve rolling six syscall numbers, not to mention handling the 64bit padding in one of mknod() or mknodat(). As the guy who did the last type bump that invasive, Just Say No. Philip Guenther
Re: tap(4) minor number too large
On Sun, Nov 11, 2018 at 08:52:39PM -0800, Greg Steuck wrote:
> I was playing with `ifconfig tapN create`. It appears some devices can be
> created outside the useful range. E.g.
>
> % for i in {23..25}; do \
>dev=tap$(printf "%d" $((1 << $i))) && \
>doas ifconfig $dev destroy ; \
>doas ifconfig $dev create && \
>ifconfig $dev && \
> (cd /dev && doas ./MAKEDEV $dev); \
> done
> tap8388608: flags=8802 mtu 1500
> lladdr fe:e1:ba:d0:af:7c
> index 85 priority 0 llprio 3
> groups: tap
> status: no carrier
> tap16777216: flags=8802 mtu 1500
> lladdr fe:e1:ba:d1:b4:0e
> index 86 priority 0 llprio 3
> groups: tap
> status: no carrier
> mknod: major or minor number too large (93 16777216)
> tap33554432: flags=8802 mtu 1500
> lladdr fe:e1:ba:d2:14:9e
> index 87 priority 0 llprio 3
> groups: tap
> status: no carrier
> mknod: major or minor number too large (93 33554432)
>
> Is there some utility in having tap devices with ids outside 24 bit range
> that I'm overlooking? They don't seem to be fit for their stated purpose of
> being open'able as mknod doesn't work for such numbers.
A devices major and minor are all stored as part of a single 32 bit
number. 8 of the bits are for the major, 24 for the minor.
> I don't know how to make a call about restricting such device creation with
> tools or syscalls. Is the current state the local optimum?
If you can trick someone into implementing 64bit device ids you can have
more than your 16 millionth tap device.
> Thanks
> Greg
>
> --
> nest.cx is Gmail hosted, use PGP for anything private. Key:
> http://goo.gl/6dMsr
> Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
tap(4) minor number too large
I was playing with `ifconfig tapN create`. It appears some devices can be
created outside the useful range. E.g.
% for i in {23..25}; do \
dev=tap$(printf "%d" $((1 << $i))) && \
doas ifconfig $dev destroy ; \
doas ifconfig $dev create && \
ifconfig $dev && \
(cd /dev && doas ./MAKEDEV $dev); \
done
tap8388608: flags=8802 mtu 1500
lladdr fe:e1:ba:d0:af:7c
index 85 priority 0 llprio 3
groups: tap
status: no carrier
tap16777216: flags=8802 mtu 1500
lladdr fe:e1:ba:d1:b4:0e
index 86 priority 0 llprio 3
groups: tap
status: no carrier
mknod: major or minor number too large (93 16777216)
tap33554432: flags=8802 mtu 1500
lladdr fe:e1:ba:d2:14:9e
index 87 priority 0 llprio 3
groups: tap
status: no carrier
mknod: major or minor number too large (93 33554432)
Is there some utility in having tap devices with ids outside 24 bit range
that I'm overlooking? They don't seem to be fit for their stated purpose of
being open'able as mknod doesn't work for such numbers.
I don't know how to make a call about restricting such device creation with
tools or syscalls. Is the current state the local optimum?
Thanks
Greg
--
nest.cx is Gmail hosted, use PGP for anything private. Key:
http://goo.gl/6dMsr
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
