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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 10 Oct 2020 20:55:41 -0700 From: Xie He <xie.he.0141@...il.com> To: Cong Wang <xiyou.wangcong@...il.com> Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, Network Development <netdev@...r.kernel.org>, syzbot <syzbot+4a2c52677a8a1aa283cb@...kaller.appspotmail.com>, William Tu <u9012063@...il.com> Subject: Re: [Patch net] ip_gre: set dev->hard_header_len properly On Sat, Oct 10, 2020 at 2:49 PM Xie He <xie.he.0141@...il.com> wrote: > > Another reason why tunnel devices usually don't provide > header_ops->create might be to keep consistency with TAP devices. TAP > devices are just like tunnel (TUN) devices except that they use an > additional Ethernet header after the tunnel headers. I guess that TAP > devices would usually use Ethernet's header_ops to expose only the > Ethernet header to the user, but hide the outer tunnel headers from > the user and let them be constructed on the transmission path (so that > TAP devices would appear exactly like Ethernet devices). If we want to > keep TUN devices consistent with TAP devices, we should hide the > tunnel headers from the user for TUN devices, too. Actually there's a "Universal TUN/TAP driver" in the kernel, which passes L3 packets or Ethernet frames (that are being sent) back to the user space and lets a user space program add the tunnel headers. https://www.kernel.org/doc/Documentation/networking/tuntap.rst In this case, we are not able to construct the tunnel headers until we pass the packets / Ethernet frames back to the user space to the user space program. We can only hide the tunnel headers. To keep other TUN/TAP devices in the kernel consistent with the "Universal TUN/TAP driver", we should hide the tunnel headers from the user for those devices, too. > Actually, a lot of devices expose a fake L2 header in header_ops, > instead of their real L2 header anyway. Wi-Fi devices usually pretend > to be Ethernet devices and expose an Ethernet header in header_ops. So > I think it is acceptable to not expose the real L2 header in > header_ops. (This is also what needed_headroom is created for - to > request additional header space for headers not exposed in > header_ops.)
Powered by blists - more mailing lists