Bug 247201 - stat()'ing /dev/tap results in a new interface
Summary: stat()'ing /dev/tap results in a new interface
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-12 10:40 UTC by Fabian Keil
Modified: 2020-06-12 11:49 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Keil 2020-06-12 10:40:58 UTC
stat()'ing /dev/tap (with "stat" or "ls -l") results in a new interface:

# uname -a
FreeBSD  13.0-CURRENT FreeBSD 13.0-CURRENT #0 r361779: Thu Jun  4 05:01:54 UTC 2020     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
# ifconfig | grep ^tap
# stat /dev/tap
1895890688 93 crw------- 1 uucp dialer 93 0 "Jun 12 12:25:33 2020" "Jun 12 12:25:33 2020" "Jun 12 12:25:33 2020" "Dec 31 23:59:59 1969" 4096 0 0 /dev/tap
# ifconfig | grep ^tap
tap0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500

The issue is also present in earlier versions such as 11/stable where dtrace shows the following stack:

fk@t520 ~ $sudo dtrace -n "fbt:if_tap:tapcreate:entry {stack()}"
dtrace: description 'fbt:if_tap:tapcreate:entry ' matched 1 probe
CPU     ID                    FUNCTION:NAME
  1  44398                  tapcreate:entry 
              if_tap.ko`tap_clone_create+0x71
              kernel`if_clone_createif+0xb3
              if_tap.ko`tapclone+0x1af
              kernel`devfs_lookup+0x59e
              kernel`VOP_LOOKUP_APV+0x7a
              kernel`lookup+0x6d1
              kernel`namei+0x455
              kernel`kern_statat+0x9a
              kernel`sys_lstat+0x30
              kernel`amd64_syscall+0xa86
              kernel`0xffffffff8085cd40

^C
Comment 1 Yuri Pankov freebsd_committer freebsd_triage 2020-06-12 10:45:35 UTC
You can even just `touch /dev/tap` for this to work, it is documented in tap(4), and can be disabled using net.link.tap.devfs_cloning tunable, there's a warning about that though.  Same is true for tun(4), BTW.
Comment 2 Fabian Keil 2020-06-12 11:00:48 UTC
Quoting the man page:
     If	the sysctl(8) variable net.link.tap.devfs_cloning is non-zero, the tap
     interface permits opens on	the special control device /dev/tap.  When
     this device is opened, tap	will return a handle for the lowest unused tap
     device (use devname(3) to determine which).
https://www.freebsd.org/cgi/man.cgi?query=tap&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE&arch=default&format=html

It does not mention that stat()'ing is sufficient to trigger this mechanism.
Comment 3 Kyle Evans freebsd_committer freebsd_triage 2020-06-12 11:49:39 UTC
Yeah, need to figure out an appropriate place to describe it so that we're not repeating it everywhere... across the board, devfs cloning will trigger on any lookup of a name that doesn't exist. This is why, e.g., chmod 0755 /dev/tun can leave you with three extra tun devices.