| created | 2024-11-23T16:44:27Z |
|---|---|
| begin | 2024-11-17T00:00:00Z |
| end | 2024-11-18T00:00:00Z |
| path | src/sys |
| commits | 5 |
| date | 2024-11-17T00:25:07Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if_tun.c | log | diff | annotate |
| src/sys/net/if_tun.h | log | diff | annotate | |
| message |
provide network offloads between the kernel and userland again userland can request that network packets that are read from or written to the device special file get prepended with a "tun_hdr" struct. this struct contains bits which say what offloads are requested for the packet, including things like ip/tcp/udp/icmp checksums, tcp segmentation offloads, or ethernet vlan tags. userland can write a packet with any of these offloads requested into the kernel at any time, but has to request which ones it's able to handle coming from the kernel. enabling the tun_hdr struct and which offloads userland can handle is done with a new TUNSCAP ioctl. this is based on the virtio_net_hdr in linux, which jan@ actually implemented and had working with vmd. however, claudio@ and i strongly opposed to what feels like a layer violation by pulling virtio structures into the tun driver, and then trying to emulate virtio/linux semantics in our network stack, and playing catch up when the "upstream" projects decide to change the shape or meaning of these bits. tun_hdr is specific to the openbsd network stack and it's semantics, which simplifies our kernel implementation. jan has been pretty gracious about the extra work on the vmd side of things. tested by and ok jan@ ok claudio@ sthen@ backed this out cos of confusion with the ioctl numbers i picked to controlling this feature. i've picked new numbers that don't conflict this time. |
|||
| date | 2024-11-17T12:21:48Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/bpf.c | log | diff | annotate |
| message |
make sure bpfsdetach is holding a bpf_d ref when invalidating stuff. when bpfsdetach is called by an interface being destroyed, it iterates over the bpf descriptors using the interface and calls vdevgone and klist_invalidate against them. however, i'm not sure the reference the interface holds against the bpf_d is accounted for properly, so vdevgone might drop it to 0 and free it, which makes the klist_invalidate a use after free. avoid this by taking a bpf_d ref before calling vdevgone and klist_invalidate so the memory can't be freed out from under the feet of bpfsdetach. Reported-by: [email protected] i wasn't able to reproduce whatever syzkaller did. it's possible this is a double free, but we'll wait and see if it pops up again. ok mpi@ |
|||
| date | 2024-11-17T16:35:05Z | |||
|---|---|---|---|---|
| author | tobhe | |||
| files | src/sys/arch/arm64/conf/GENERIC | log | diff | annotate |
| message |
add qccpucp to GENERIC ok patrick@ |
|||
| date | 2024-11-17T23:21:45Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if_tun.c | log | diff | annotate |
| message | include tun_hdr in the length reported by FIONREAD and kq if it's enabled. | |||
| date | 2024-11-17T23:31:01Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if_tun.c | log | diff | annotate |
| message |
bump the "mru" up to MAXMCLBYTES. there's no reason to limit tun/tap to small packets. ok claudio@ |
|||