Build date: 1731884403 - Sun Nov 17 23:00:03 UTC 2024
Build cvs date: 1731861305 - Sun Nov 17 16:35:05 UTC 2024
Build id: 2024-11-18.1
Build tags: amd64-regress ports sysupgrade

Applied the following diff(s):
/home/anton/tmp/robsd/src-ptrace-xstate.diff
/home/anton/tmp/robsd/src-sys-em.diff
/home/anton/tmp/robsd/src-sys-newvers.diff
/home/anton/tmp/robsd/src-sys-uhidev-sispm.diff
/home/anton/tmp/robsd/src-sysupgrade.diff
/home/anton/tmp/robsd/src-tftpd-quirk.diff

? regress/sys/arch/amd64/ddb
? regress/sys/kern/ptrace/xstate
P lib/libcrypto/ec/ec_lib.c
P lib/libcrypto/ec/ecp_methods.c
P share/man/man4/tun.4
P sys/arch/arm64/conf/GENERIC
P sys/net/bpf.c
P sys/net/if_tun.c
P sys/net/if_tun.h

commit JwwFKPE6HznkFQAb
Author: tobhe
Date: 2024/11/17 16:35:05

  add qccpucp to GENERIC

  ok patrick@

  sys/arch/arm64/conf/GENERIC

commit zEWGAQkcPSeRXy1R
Author: dlg
Date: 2024/11/17 12:21:48

  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: syzbot+b3927f8ad162452a2f39@syzkaller.appspotmail.com

  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@

  sys/net/bpf.c

commit wPHLzyvZzSENyzqp
Author: tb
Date: 2024/11/17 10:48:13

  ec_lib: zap a useless comment

  lib/libcrypto/ec/ec_lib.c

commit 9MOABMwD0eiKgdnW
Author: dlg
Date: 2024/11/17 09:19:46

  describe the endianness of tun_hdr

  share/man/man4/tun.4

commit vUiJ3nHcKOtn2xUc
Author: tb
Date: 2024/11/17 08:19:08

  Minor simplifications in ec_cmp()

  lib/libcrypto/ec/ecp_methods.c

commit o7fyT3uAQMaxxuky
Author: jmc
Date: 2024/11/17 07:44:47

  minor grammar/macro fixes;

  share/man/man4/tun.4

commit C8USm2LXuo4ilT6S
Author: tb
Date: 2024/11/17 06:33:35

  Rewrite EC_GROUP_cmp()

  Use better variable names (cf. https://jmilne.org/math/tips.html#4) and
  avoid the weird style of assigning to r (what does r stand for anyway?)
  and short circuiting subsequent tests using if (r || ...). Also, do not
  reuse the variables for order and cofactor that were previously used for
  the curve coefficients.

  ok jsing

  lib/libcrypto/ec/ec_lib.c

commit CChaA2homd0d3V4A
Author: dlg
Date: 2024/11/17 01:44:25

  try documenting tun_hdr

  share/man/man4/tun.4

commit 9HAFuFMs2enIyXvb
Author: dlg
Date: 2024/11/17 00:51:04

  make a first pass at documenting the network offload support.

  the ioctls are here, the offload header is next.

  share/man/man4/tun.4

commit 6mCOL4eCsnWJFrFU
Author: dlg
Date: 2024/11/17 00:25:07

  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.

  sys/net/if_tun.c
  sys/net/if_tun.h