OpenBSD cvs log

created 2025-02-16T07:54:51Z
begin 2025-02-14T00:00:00Z
end 2025-02-15T00:00:00Z
path src/sys
commits 7

date 2025-02-14T03:11:05Z
author hastings
files src/sys/dev/fdt/files.fdt log diff annotate
src/sys/dev/fdt/mtrng.c log diff annotate
message Add mtrng(4), supporting the 32-bit random number generator on MediaTek SoCs.

ok kettenis@

date 2025-02-14T04:56:26Z
author hastings
files src/sys/arch/arm64/conf/GENERIC log diff annotate
src/sys/arch/arm64/conf/RAMDISK log diff annotate
message Enable mtrng(4).

ok kettenis@

date 2025-02-14T04:56:34Z
author hastings
files src/sys/arch/armv7/conf/GENERIC log diff annotate
src/sys/arch/armv7/conf/RAMDISK log diff annotate
message Enable mtrng(4).

ok kettenis@

date 2025-02-14T13:14:13Z
author dlg
files src/sys/net/if_bridge.c log diff annotate
src/sys/net/if_sec.c log diff annotate
src/sys/netinet/ip_ipsp.h log diff annotate
src/sys/netinet/ip_output.c log diff annotate
src/sys/netinet/ipsec_output.c log diff annotate
src/sys/netinet6/ip6_output.c log diff annotate
message add tunneldf support to sec(4)

sec(4) is a very thin wrapper around the existing ipsec output
processing for encapsulating packets, and inherited the behaviour
that the DF flag was propagated from the encapsulated packet to the
outer ip header.

this means if the sec(4) interface has a large mtu and is carrying
packets with DF set over a network that can't transport large(r)
packets, these packets are effectively dropped. ipsec applied via
the SPD copes with this by having SAs figure out the path mtu and
using that when applying policy, but sec(4) is an interface, so the
network stack uses the interface mtu rather than the associated
SA path mtu.

rfc4459 discusses this kind of problem has offers a variety of
solutions. this implements one of the simpler options, which is to
allow the tunnel endpoints to manage the DF regardless of the payload
and reassemble the encapsulated packets.

to actually do this, ipsec output packet processing has to be able
to take an argument that says how you want DF to be handled.

in the future we're going to look at how we can use the path mtu
determined by the ipsec SA to try and implement one of the other
solutions from the RFC, which is to signal the lower mtu to the
sources of tunnelled packets.

tested by and ok claudio@

date 2025-02-14T13:29:00Z
author ratchov
files src/sys/dev/audio.c log diff annotate
src/sys/dev/wscons/wskbd.c log diff annotate
src/sys/kern/kern_sysctl.c log diff annotate
src/sys/sys/sysctl.h log diff annotate
message Add the kern.audio.kbdcontrol sysctl(2) variable

If set to 0, the volume keys on multimedia keyboards are handled
as regular keys, allowing programs to use them. The default is 1,
i.e. the current behavior.

ok armani, kettenis, mvs

date 2025-02-14T18:36:04Z
author kettenis
files src/sys/arch/arm64/arm64/pmap.c log diff annotate
message Add support for device mappings in pmap_kenter_pa(9) the same way we
handle those in pmap_enter(9).

ok jca@

date 2025-02-14T18:42:43Z
author kettenis
files src/sys/arch/arm64/dev/aplsmc.c log diff annotate
src/sys/arch/arm64/dev/rtkit.c log diff annotate
src/sys/dev/pci/drm/apple/apldcp.c log diff annotate
message It is important that we map memory with the right attributes otherwise
we may trigger an SError. The crashlog entries for the SMC live in SRAM
which needs to be mapped as device memory. To make this possible, make
the rk_logmap() rtkit callback function return the desired memory
attributes in the low bits of the address, using PMAP_NOCACHE or
PMAP_DEVICE defines.

Rewrite the DCP implementation of rk_logmap() to do a better job ati
determining the correct mapping. The current code would fail in some
cases (i.e. on the M1 Pro MacBook Pro) and map some unused address as
normal non-cachable which could also trigger an SError.

ok jca@