OpenBSD src changes summary for 2017-11-21
==========================================

bin/ksh                                 gnu
lib/libc                                regress/bin
share/man                               sys/netinet
sys/netinet6                            usr.sbin/kvm_mkdb
usr.sbin/smtpd                          

== bin =============================================================== 01/07 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin

ksh

  ~ history.c                             

  > Initialize *histbase to NULL to fix a bus error in emacs editing mode
  > found by anton. To reproduce, run "env EDITOR=emacs MALLOC_OPTIONS=J ksh"
  > then press "^[_".
  > ok anton, jca (tb@)

== gnu =============================================================== 02/07 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu

gnu

  ~ llvm/lib/Target/X86/X86RegisterInfo.td

  > The compiler is generally free to allocate general purpose registers in
  > whatever
  > order it chooses. Reasons for choosing one register before another usually
  > incl
  > ude compiled instruction size (avoidance of REX prefixes, etc.) or usage
  > convent
  > ions, but somehow haven't included security implications in the compiled
  > bytecod
  > e. Some bytecode is more useful in polymorphic ROP sequences than others,
  > so it
  > seems prudent to try to avoid that bytecode when possible.
  > This patch moves EBX/RBX towards the end of the allocation preference for
  > 32 and
  > 64 bit general purpose registers. Some instructions using RBX/EBX/BX/BL as
  > a de
  > stination register end up with a ModR/M byte of C3 or CB, which is often
  > useful
  > in ROP gadgets. Because these gadgets often occur in the middle of
  > functions, th
  > ey exhibit somewhat higher diversity than some other C3/CB terminated
  > gadgets. T
  > his change removes about 3% of total gadgets from the kernel, but about 6%
  > of un
  > ique gadgets.
  > There are other possible changes in this direction. BX/BL are obvious next
  > targe
  > ts for avoidance, and MM3/XMM3 may also be useful to try to avoid if
  > possible.
  > ok deraadt@ (mortimer@)

== lib =============================================================== 03/07 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib

libc

  ~ stdio/vfprintf.c                      

  > Use a simple forward search to find '%' in the format string instead of
  > using mbrtowc(3). Thus, we now treat the format string as a bytestring,
  > not as a multibyte character string.
  > We think that ANSI C made a small error when adding wide characters:
  > The committees essentially replaced "characters" with "wide characters"
  > in the existing printf documentation, which was written before the
  > concept of processing was established. Doing processing on the format
  > string would break some 8-bit format strings in the wild, and that
  > isn't something these committees gave themselves license to do.
  > Based on the "10x printf speedup" commit from android found by tedu:
  > https://github.com/aosp-mirror/platform_bionic/commit/5305a4d4a723b06494b93
  > f2df81733b83a0c46d3
  > Thanks to millert and schwarze for digging into the history and
  > testing *printf behavior on other platforms.
  > ok deraadt, millert (tb@)

  ~ arch/arm/sys/Ovfork.S                 ~ arch/arm/sys/brk.S
  ~ arch/arm/sys/sbrk.S                   

  > Avoid .align 0.  Clang's integrated assembler actually honors this
  > directive
  > and the resulting byte-alignment triggers unaligned access.
  > ok patrick@, deraadt@ (kettenis@)

== regress =========================================================== 04/07 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress

bin

  ~ ksh/edit/edit.c                       

  > Do not exit 0 if the program was terminated due to receipt of a signal
  > other
  > than SIGHUP. (anton@)

  ~ ksh/edit/emacs.sh                     ~ ksh/edit/subr.sh

  > Add tests for emacs editing mode in ksh. While here, improve the output on
  > test
  > failure. (anton@)

== share ============================================================= 05/07 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share

man

  ~ man5/port-modules.5                   

  > Delete mentions of the gettext module, which has been obsoleted and
  > removed. (naddy@)

== sys =============================================================== 06/07 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys

netinet

  ~ ip_carp.c                             

  > Move the addrhook disestablish from carpdetach() to carp_clone_destroy()
  > to make it symmetric to the addrhook establish which is being done in
  > carp_clone_create().  This fixes the issue that carp does not recognize
  > address changes on the carp after an interface has detached, which could
  > cause issues like carp not recovering or even panics.  Unfortunately
  > there are more bugs lurking in carp.
  > ok bluhm@ (patrick@)

netinet6

  ~ ip6_forward.c                         

  > Do not assume if_get(9) returns a non NULL ifp when using a route
  > interface index.
  > This assumption is true for the moment iff the route lookup *and* the
  > if_get() are done under KERNEL_LOCK().  This is not the case here.
  > Found the hardway by Hrvoje Popovski.
  > ok florian@, visa@, bluhm@ (mpi@)

== usr.sbin ========================================================== 07/07 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin

kvm_mkdb

  ~ kvm_mkdb.c                            

  > The call to setegid(2) was replaced with setresgid(2) a while ago.
  > Adjust error message accordingly. (tb@)

smtpd

  ~ ca.c                                  ~ lka.c
  ~ mda.c                                 ~ mta.c
  ~ queue.c                               ~ smtp.c
  ~ smtpd.c                               

  > no need to check the sending process in imsg handlers when there is no
  > ambiguity: just use a single switch.
  > ok gilles@ sunil@ (eric@)

===============================================================================
_______________________________________________
odc mailing list
odc@squish.net
http://www.squish.net/mailman/listinfo/odc

Reply via email to