OpenBSD src changes summary for 2017-03-21 ==========================================
Makefile.cross sbin/dhclient sbin/ifconfig sbin/iked sbin/route sys/arch/amd64/amd64 sys/arch/arm/arm sys/arch/arm/cortex sys/arch/arm64/arm64 sys/arch/arm64/include sys/kern sys/net80211 usr.bin/mandoc usr.bin/tmux usr.sbin/bgpd usr.sbin/dhcpd usr.sbin/dhcrelay usr.sbin/dhcrelay6 usr.sbin/dvmrpd usr.sbin/eigrpd usr.sbin/httpd usr.sbin/ifstated usr.sbin/iscsid usr.sbin/ldapd usr.sbin/ldpd usr.sbin/npppd usr.sbin/ntpd usr.sbin/ospf6d usr.sbin/ospfd usr.sbin/relayd usr.sbin/ripd usr.sbin/route6d usr.sbin/rtadvd usr.sbin/slaacd usr.sbin/smtpd usr.sbin/snmpd usr.sbin/switchd usr.sbin/vmd usr.sbin/ypldap == Makefile.cross ==================================================== 01/05 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/Makefile.cross Makefile.cross > Export CROSSDIR so that the two users (ld.so and binutils) of that > variable actually work correctly. While there, adjust a bit for > consistency. > "nobody will complain if you break it ;)" kettenis@ (patrick@) == sbin ============================================================== 02/05 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin dhclient ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) ifconfig ~ ifconfig.c > Replace a magic number with the corresponding macro from ieee80211_ioctl.h. > No functional change. > ok deraadt@ tb@ (stsp@) iked ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) route ~ route.c > getnameinfo errors should go to stderr & should print what's going on. > Pointed out by & ok bluhm > While here print prefixlen with %u, pointed out by bluhm, too. (florian@) == sys =============================================================== 03/05 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys arch/amd64/amd64 ~ vmm.c > CPUID feature 0x80000000 emulation fell through to 0x80000001, which > resulted in wrong cpu information being passed to the guest. Specifically > this breaks Linux guests as with the fallthrough, CPUID_LONG was cleared, > and Linux thought it was runinng on a machine incapable of 64-bit mode. > OpenBSD/NetBSD guests don't check this flag and thus weren't affected. > (mlarkin@) ~ vmm.c > Don't allow the guest to clear CR0_NE or CR4_VMXE. While we should be > using the "must be clear / must be set" masks for these registers, I'd > like to know (for now) when guest VMs manipulate bits in these registers > in an unexpected way. This is needed for Linux guests, as they > unconditionally set CR0 without NE, and CR4 without VMXE. (mlarkin@) arch/arm/arm ~ sys_machdep.c > Avoid panic in arm_sync_icache() by only flushing the parts of the address > space for which we have a userland mapping. > ok jca@ (kettenis@) arch/arm/cortex ~ ampintc.c > As a first step towards SMP, use an array for the destination masks with > an element for each CPU. Use this mask directly instead of converting > it into a cpu number and back into a mask again when routing interrupts. > This avoids the need to handle uniprocessor systems in a special way > as they will return 0 as the mask (the relevant register is defined as RAZ) > and ignore what's written into the destination registers (the relevant > registers are defined as WI). > Future code that hatches the secondary CPUs will have to call into the > driver to establish the masks for those CPUs. > ok patrick@ (kettenis@) arch/arm64/arm64 ~ process_machdep.c > Revise the definition of "struct reg" to have a layout compatible with > other > operating systems. Implement process_read_regs() and make > process_read_fpregs() clear the struct fpreg to avoid leaking kernel stack > contents. This makes core dumps actually usable. > ok drahn@ (kettenis@) arch/arm64/include ~ reg.h > Revise the definition of "struct reg" to have a layout compatible with > other > operating systems. Implement process_read_regs() and make > process_read_fpregs() clear the struct fpreg to avoid leaking kernel stack > contents. This makes core dumps actually usable. > ok drahn@ (kettenis@) kern ~ exec_elf.c TAGGED OPENBSD_5_9 > OpenBSD 5.9 Errata 037: SECURITY FIX: March 20, 2017 > MFC sys/kern/exec_elf.c exec_elf.c rev v 1.140 kettenis > Initialize the stack buffer used to build the auxiliary vector to zero to > avoid leaking the contents of the kernel stack into userspace. > ok guenther@, deraadt@ (benno@) ~ exec_elf.c TAGGED OPENBSD_6_0 > OpenBSD 6.0 Errata 020: SECURITY FIX: March 20, 2017 > MFC sys/kern/exec_elf.c exec_elf.c rev v 1.140 kettenis > Initialize the stack buffer used to build the auxiliary vector to zero to > avoid leaking the contents of the kernel stack into userspace. > ok guenther@, deraadt@ (benno@) net80211 ~ ieee80211_ioctl.c > When a new WPA key is set while WEP is enabled, disable WEP, > and when a new WEP key is set while WPA is enabled, disable WPA. > Prevents unusable configurations where both WEP and WPA are active > and makes switching between WEP/WPA networks easier. > ok deraadt@ tb@ sthen@ (stsp@) == usr.bin =========================================================== 04/05 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin mandoc ~ man.1 > delete documentation of a hack that was removed years ago (schwarze@) ~ mandoc.1 > simplify .Nd; to display manuals, use man(1) instead; > OK jmc@ (schwarze@) tmux ~ window.c > Fix pane movement by direction (up, down, left, right) when > pane-border-status is set, from KOIE Hidetaka. (nicm@) ~ window-copy.c > Fix movement after select-line, from Omar Sandoval. (nicm@) ~ tmux.c > Use uid_t for UID not u_int. (nicm@) == usr.sbin ========================================================== 05/05 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin bgpd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) dhcpd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) dhcrelay ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) dhcrelay6 ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > I have missed dhcrelay6 and slaacd in my previous conversion as they > were added recently. (bluhm@) dvmrpd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) eigrpd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) httpd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) ifstated ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) iscsid ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) ldapd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) ldpd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) npppd ~ npppd/log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) ntpd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) ospf6d ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) ospfd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) relayd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) ripd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) route6d ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) rtadvd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) slaacd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > I have missed dhcrelay6 and slaacd in my previous conversion as they > were added recently. (bluhm@) smtpd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) snmpd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) switchd ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) vmd ~ ns8250.c ~ vm.c ~ vmm.h > Fix two errors in NS8250 (UART) emulation. The first error zeroed out the > high bits of %eax on reading register data from the emulated UART ports. > The second error didn't properly assert the TXRDY bit during init - > this bit was only set after the first character was sent. Both these > bugs caused seabios to not be able to output any data. Found during the > recent effort to get Linux guests booting. (mlarkin@) ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) ypldap ~ log.c > From a syslog perspective it does not make sense to log fatal and > warn with the same severity. Switch log_warn() to LOG_ERR and keep > fatal() at LOG_CRIT. > OK reyk@ florian@ (bluhm@) =============================================================================== _______________________________________________ odc mailing list [email protected] http://www.squish.net/mailman/listinfo/odc
