| created | 2023-08-12T21:15:23Z |
|---|---|
| begin | 2023-08-07T00:00:00Z |
| end | 2023-08-08T00:00:00Z |
| path | src/sys |
| commits | 8 |
| date | 2023-08-07T01:44:51Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/netinet/ip_ipsp.h | log | diff | annotate |
| message |
start adding support for route-based ipsec vpns. rather than use ipsec flows (aka, entries in the ipsec security policy database) to decide which traffic should be encapsulated in ipsec and sent to a peer, this tweaks security associations (SAs) so they can refer to a tunnel interface. when traffic is routed over that tunnel interface, an ipsec SA is looked up and used to encapsulate traffic before being sent to the peer on the SA. When traffic is received from a peer using an interface SA, the specified interface is looked up and the packet is handed to it so it looks like packets come out of the tunnel. to support this, SAs get a TDBF_IFACE flag and iface and iface_dir fields. When TDBF_IFACE is set the iface and dir fields are considered valid, and the tdb/SA should be used with the tunnel interface instead of the SPD. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@ |
|||
| date | 2023-08-07T01:57:33Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if_sec.c | log | diff | annotate |
| src/sys/net/if_sec.h | log | diff | annotate | |
| message |
add sec(4) to support route based ipsec vpns. ipsec security associations (SAs, aka tdbs inside the kernel) can now specify that they're to be used with an interface (using TDBF_IFACE) rather than the ipsec security policy database. sec(4) is the driver providing that interface. the name is specifically chosen to not be ipsec(4) because that's already taken by the manpage for the ipsec stack generally. sec(4) is short, easy to type and pronounce, and kind of sounds like ipsec anyway. the names for this type of interface in other platforms seems to be universally terrible and too generic, so i didn't want to copy any of those either. sec(4) can be considered equivalent to gif(4) protected by ipsec, and on the wire it actually looks the same. sec(4) exists to better support how security associations for route-based ipsec VPNs are negotiated and to avoid SPD entries for them. the code is a little green, but i'm putting it in now so it can be hacked on in the tree. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@ |
|||
| date | 2023-08-07T01:59:38Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/conf/files | log | diff | annotate |
| message |
wire sec(4) into the kernel config. this makes #include "sec.h" and #if NSEC > 0 work in kernel code. |
|||
| date | 2023-08-07T02:47:55Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/amd/amdgpu/amdgpu_devlist.h | log | diff | annotate |
| message |
744c rev ce is Radeon RX 7900 GRE found in AMD Software: Adrenalin Edition 23.7.2 |
|||
| date | 2023-08-07T03:35:06Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/pfkeyv2.c | log | diff | annotate |
| src/sys/net/pfkeyv2.h | log | diff | annotate | |
| src/sys/net/pfkeyv2_convert.c | log | diff | annotate | |
| src/sys/net/pfkeyv2_parsemessage.c | log | diff | annotate | |
| message |
add a struct sadb_x_iface message for interface SAs this allows userland to install (and see) security associations for route-based ipsec vpns. if this message is part of an SA, it causes the TDBF_IFACE flag and associated fields in a tdb to be set. the interface unit field in this message maps to minor number of the sec(4) interface you want to the SA to work with. ie, set the sadb_x_iface_unit field in struct sadb_x_iface to 1 to set up an SA for use with sec1. the sadb_x_iface_direction in the message uses IPSP_DIRECTION_IN and IPSP_DIRECTION_OUT to specify in which direction that SA is supposed to process traffic. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@ |
|||
| date | 2023-08-07T03:43:57Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/netinet/ip_ipsp.c | log | diff | annotate |
| src/sys/netinet/ipsec_input.c | log | diff | annotate | |
| message |
add the glue between ipsec security associations and sec(4) interfaces. if TDBF_IFACE is set on a tdb, the ipsec stack will pass it to the sec(4) driver to keep track of instead of wiring it up for security associations to use. when sec(4) transmits a packet, it will look up it's list of tdbs to find the right SA to encrypt and send the packet out with. if an incoming ipsec packet arrives with TDBF_IFACE set, it's passed to sec(4) to be injected back into the network stack as if it was received on the sec interface, instead of being reinjected into the IP stack like normal SA/SPD processing does. note that this means you do not have to configure tunnel endpoints on sec(4) interfaces, instead you line the interface unit number in the ipsec config up with the minor number of the sec(4) interfaces. the peer IPs used on the SAs are what's used as the traffic endpoints. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@ |
|||
| date | 2023-08-07T17:11:13Z | |||
|---|---|---|---|---|
| author | miod | |||
| files | src/sys/arch/sparc64/sparc64/clock.c | log | diff | annotate |
| message |
Revert 1.43 and always make our own mapping of the Mostek chip. Trying to reuse the prom mapping here is a bad idea because we alter its writeability and the prom will not always expect this. Repairs powerdown on Tapdole Ultrabook IIe. discussed with and ok kettenis@ |
|||
| date | 2023-08-07T20:28:47Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/ic/dwqe.c | log | diff | annotate |
| message |
Raise transmit threshold to 512 bytes. This makes dwqe(4) work at 1000baseT. We still see a small number of underflow errors when hammering the interface with packets, but it is defenitely usable. While there, make sure we count transmit errors. ok jmatthew@ |
|||