OpenBSD cvs log

created 2019-08-24T16:58:46Z
begin 2019-08-21T00:00:00Z
end 2019-08-22T00:00:00Z
path src/sys
commits 4

date 2019-08-21T02:18:33Z
author jsg
files src/sys/dev/pci/vga_pci_common.c log diff annotate
src/sys/dev/pci/drm/amd/amdgpu/amdgpu_devlist.h log diff annotate
message Add simple amdgpu pci id devlist for the ramdisk to determine if
aperture is needed. Skip SI/CIK ids as we don't build amdgpu with
SI/CIK support (radeondrm covers these) and skip VEGA20 ids we
don't match on as they are flagged AMD_EXP_HW_SUPPORT.

date 2019-08-21T15:32:18Z
author florian
files src/sys/net/if.c log diff annotate
src/sys/netinet6/in6_ifattach.c log diff annotate
src/sys/netinet6/in6_ifattach.h log diff annotate
src/sys/netinet6/ip6_input.c log diff annotate
message Remove support for semantically opace interface identifiers (RFC 7217)
for IPv6 link local addresses.

Some hosting and VM providers route customer IPv6 prefixes to link
local addresses derived from ethernet MAC addresses (RFC 2464). This
leads to hard to debug IPv6 connectivity problems and is probably not
worth the effort.

RFC 7721 lists 4 weaknesses:

3.1. Correlation of Activities over Time & 3.2. Location Tracking
These are still possible with RFC 7217 addresses for an adversary
connected to the same layer 2 network (think conference wifi). Since
the link local prefix stays the same (fe80::/64) the link local
addresses do not change between different networks.
An adversary on the same layer 2 network can probably track ethernet
MAC addresses via different means, too.

3.3. Address Scanning & 3.4. Device-Specific Vulnerability Exploitation
These now become possible, however, as noted above a layer 2 adversary
was probably able to do this via different means.

People concerned with these weaknesses are advised to use
ifconfig lladdr random.
OK benno
input & OK kn

date 2019-08-21T16:14:34Z
author visa
files src/sys/arch/mips64/include/pmap.h log diff annotate
src/sys/arch/mips64/mips64/context.S log diff annotate
src/sys/arch/mips64/mips64/pmap.c log diff annotate
message Fix a race in invalidation of remote TLB entries.

If a CPU updates a pmap concurrently with the activation of that pmap
on another CPU, invalidation of TLB entries might be incomplete.
It is also possible that a CPU altogether stops updating its TLB.

Prevent the race by synchronizing pmap activations and logic that
determines where to send TLB invalidation IPIs.

To avoid mutex wait without ability to process IPIs, the context switch
code is adjusted to call pmap_activate() with interrupts enabled.
In practice, interrupts up to IPL_SCHED are still disabled on context

date 2019-08-21T20:44:09Z
author cheloha
files src/sys/arch/amd64/isa/clock.c log diff annotate
src/sys/arch/i386/isa/clock.c log diff annotate
src/sys/arch/macppc/macppc/clock.c log diff annotate
src/sys/conf/param.c log diff annotate
src/sys/kern/kern_sysctl.c log diff annotate
src/sys/sys/kernel.h log diff annotate
src/sys/sys/sysctl.h log diff annotate
message sysctl(2): add kern.utc_offset: successor to the DST/TIMEZONE options(4)

The DST and TIMEZONE options(4) are incompatible with KARL, so we need
some other way to compensate for an RTC running with a known offset.

Enter kern.utc_offset, an offset in minutes East of UTC. TIMEZONE has
always been minutes West, but this is inconsistent with how everyone
else talks about timezones, hence the flip.

TIMEZONE has the advantage of being compiled into the binary. Our new
sysctl(2) has no such luck, so it needs to be set as early as possible
in boot, from sysctl.conf(5), so we can correct the kernel clock from
the RTC's local time to UTC before daemons like ntpd(8) and cron(8)
start. To encourage this, kern.utc_offset is made immutable after the
securelevel(7) is raised to 1.

Prompted by yasuoka@. Discussed with deraadt@, kettenis@, yasuoka@.
Additional testing by yasuoka@.

ok deraadt@, yasuoka@