CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: an...@cvs.openbsd.org 2021/12/29 00:16:30 Modified files: regress/sys/dev/kcov: Makefile kcov.c Log message: Ensure file descriptor send/receive is not allowed.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: an...@cvs.openbsd.org 2021/12/29 00:15:13 Modified files: sys/dev: kcov.c sys/kern : uipc_usrreq.c sys/sys: kcov.h Log message: Do not allow send/receive of kcov descriptors as the file descriptor can be kept alive longer than expected causing syzkaller to no longer being able to enable remote coverage. ok visa@ Reported-by: syzbot+ab2016d729cda7b0d...@syzkaller.appspotmail.com
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: k...@cvs.openbsd.org2021/12/28 17:04:45 Modified files: sbin/fdisk : gpt.c Log message: Tweak some DEBUG output. Always put '0x' prefix in front of displayed hex values, i.e. the checksums. Add missing letoh32() so bad endian checksum is clear. Be consistent when displaying 'expected' and 'got' checksums, i.e. 'expected' == calculated checksum and 'got' == checksum found in GPT.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: m...@cvs.openbsd.org2021/12/28 17:04:35 Modified files: regress/sys/kern/unixsockets: unsopassgc.c Log message: Add unp_dispose() threads to 'unsopassgc' test.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: k...@cvs.openbsd.org2021/12/28 16:44:02 Modified files: sbin/fdisk : gpt.c Log message: Tweak some DEBUG output. 'EFI PART' reads better than "TRAP IFE" and checksums are easier to read/compare when shown in hex rather than decimal. Prompted by recent GPT vs disklabel misc@ thread concerning Rob Whitlock's problematic GPT.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2021/12/28 16:13:20 Modified files: sys/net: if_veb.c Log message: whitespace tweak, no functional change.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2021/12/28 16:10:58 Modified files: sys/net: if_veb.c Log message: it doesnt make sense to configure a vport as a span port.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2021/12/28 16:10:30 Modified files: sys/net: if_veb.c Log message: move away from using the M_PROTO1 flag to prevent loops with vports if a vlan interface is configured on a vport interface, vlan(4) will take the packet away from ether_input before the veb bridge input handler gets to clear M_PROTO1. this leaves the flag on the mbuf as it goes through the l3 stacks. if it goes back out a vport into a veb, the presence of M_PROTO1 means the packet ends up getting dropped, which is unexpected. this diff specialises vport handling by veb even more to avoid the problem the flag was handling. vports get their own bridge input handler that skips veb processing completely because a packet being received on a vport can only occur if a veb has decided to forward it there and has already processed it. when the stack sends a packet out a vport interface, then we do actual veb bridge input handling. bug reported on misc@ and the fix tested by Simon Baker
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 14:23:40 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Fix typo in comment
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: na...@cvs.openbsd.org 2021/12/28 14:14:24 Modified files: gnu/llvm/lld/ELF: Driver.cpp gnu/llvm/lld/docs: ld.lld.1 Log message: lld: restore upstream default for --[no-]allow-shlib-undefined ok patrick@ kettenis@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: na...@cvs.openbsd.org 2021/12/28 14:13:21 Modified files: gnu/llvm/lld/ELF: InputFiles.cpp Log message: lld: do not report undefined weak references in shared libraries https://github.com/llvm/llvm-project/commit/52bfd2c1ccd86ff813ee6df5a6700690acdd912f This fixes an issue introduced in D101996. A weak reference in a shared library could be incorrectly reported if there is another library that has a strong reference to the same symbol. Differential Revision: https://reviews.llvm.org/D115041 ok patrick@ kettenis@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 14:06:01 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Use lowercase letters for hexadecimal constants, as both jsing and I prefer this.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 14:00:27 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Rewrite X509v3_addr_canonize() with new accessors This is again a straightforward conversion and leads to something which matches our usual style more. ok jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 13:58:05 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Validate AFIs before sorting in X509v3_adr_canonize() Again, we're dealing with necessarily not fully validated data here, so a check up front seems prudent. ok jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 13:50:37 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Rewrite/simplify X509v3_addr_is_canonical() This is a more or less straightforward conversion using the new IPAddressFamily accessor API. As a result, some checks have become a bit stricter, which is only desirable here. ok jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 13:44:56 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Check AFI/SAFI before comparing them in X509v3_addr_is_canonical() As mentioned in a previous commit, IPAddressFamily_cmp() can't really check for trailing garbage in addressFamily->data. Since the path validation and hence the X.509 validator call X509v3_addr_is_canonical(), this deals with only partially validated data. ok jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 13:07:17 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Make IPAddressFamily_cmp() more pleasing on the eye Define and use MINIMUM() instead of a ternary operator and separate the code from the declarations. Also, we can spare a line to make the return legible instead of squeezing it into another ternary operator. addressFamily->data contains a two-bytes AFI and an optional one-byte SAFI. This function currently also compares any trailing garbage that may be present. Since comparison functions can't really error, this needs to be checked bofore it is used. Such checks will be added in subsequent commits. ok jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 12:59:33 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Style improvements in X509v3_addr_add_range() ok jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 12:56:45 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Style improvements in X509v3_addr_add_prefix() ok jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: an...@cvs.openbsd.org 2021/12/28 10:50:10 Modified files: sys/dev: kcov.c Log message: The initial kd_lookup() in kcovopen() is redundant as kcov is a cloning device. Turn it into an assertion instead to better state the expected semantics of D_CLONE. Prompted after a discussion with visa@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 10:45:41 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Another small readability tweak in X509v3_addr_inherits() Declare IPAddressFamily before using it.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 10:25:46 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Use an accessor in X509v3_addr_inherits()
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 09:40:13 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Add a comment to i2r_IPAddrBlocks that we may want/have to deal with unknown address family types. Pointed out by jsing during review.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 09:37:37 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Add a few accessors for IPAddressFamily and make first use of them One reason why this file is hard to read are endless repetitions of checks and assignments reaching deep inside structs. This can be made much more readable by adding a bunch of accessors. As a first step, we deal with IPAddressFamily, where we want to check the type of the ipAddressChoice member, check whether the inheritance element is present or access the addressOrRanges field. This diff already makes minimal use of these accessors to appease -Werror. More use and additional accessors will follow in later passes. ok inoguchi jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: o...@cvs.openbsd.org2021/12/28 09:29:59 Modified files: sys/arch/amd64/conf: Makefile.amd64 Log message: Now that -A prints -- markers as it is supposed to filter them out when doing the consistency check for locore.o; ok millert@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: o...@cvs.openbsd.org2021/12/28 09:27:53 Modified files: usr.bin/grep : util.c Log message: Fix printing of -- marker when using -A as noted by gnezdo@ ok millert@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 09:26:53 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Simplify and explain expand_addr() a bit RFC 3779 section 2.1.2 does a decent job of explaining how IP addresses are encoded in. What's stored amounts to a prefix with all trailing zero octets omitted. If there are trailing zero bits in the last non-zero octet, bs->flags & 7 indicates how many. addr_expand() expands this to an address of length 4 or 16 depending on whether we deal with IPv4 or IPv6. Since an address can be the lower or the upper bound of a prefix or address range, expansion needs to be able to zero-fill or one-fill the unused bits/octets. No other expansion is ever used, so simplify the meaning of fill accordingly. There's no need to special case the case that there are no unused bits, the masking/filling is a noop. ok jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 09:21:59 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Add a comment so I don't forget to think about input validation in make_IPAddressFamily()
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 09:10:47 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Convert make_IPAddressFamily to CBS/CBB The IPAddrBlocks type, which represents the IPAddrBlocks extension, should have exactly one IPAddressFamily per AFI+SAFI combination to be delegated. make_IPAddressFamily() first builds up a search key from the afi and safi arguments and then looks for an existing IPAddressFamily with that key in the IPAddrBlocks that was passed in. It returns that if it finds it or allocates and adds a new one. This diff preserves the current behavior that the afi and *safi arguments are truncated to 2 and 1 bytes, respectively. This may change in the future. ok inoguchi jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 09:05:24 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Remove two pointless NULL checks and allocations The ASN.1 template for IPAddressFamily doesn't mark either of its two members as optional, so they are allocated by IPAddressFamily_new(). ok inoguchi jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 08:59:13 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Check for trailing garbage in X509_addr_get_afi() Per RFC 3779 2.2.3.3, the addressFamily field contains the 2-byte AFI and an optional 1-byte SAFI. Nothing else. The optional SAFI is nowhere exposed in the API. It is used expliclty only for pretty printing. There are implicit uses in a few places, notably for sorting/comparing where trailing garbage would be erroneously taken into account. Erroring in this situation will let us avoid this in upcoming revisions. ok inoguchi jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2021/12/28 08:49:11 Modified files: lib/libcrypto/x509: x509_addr.c Log message: Convert X509v3_adr_get_afi() to CBS The manual byte bashing is performed more safely using this API which would have avoided the out-of-bounds read that this API had until a few years back. The API is somewhat strange in that it uses the reserved AFI 0 as an in-band error but it doesn't care about the reserved AFI 65535. ok inoguchi jsing
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: patr...@cvs.openbsd.org 2021/12/28 08:45:17 Modified files: gnu/lib/libcompiler_rt: Makefile Log message: Compile out-of-line helpers for atomic operations which can be enabled through -moutline-atomics. These are included by default in this updated version of compiler-rt, we just haven't enabled them yet. Some ports start to make use of that option, so it makes sense to provide these helpers. The helpers would make use of the ARMv8.1 LSE instructions, if we flagged that the running system supports those. As we do not yet have a mechanism to show support for LSE, the code will always fall back to regular atomics. Issue raised by jca@ Tested by phessler@ Input from jsg@ ok kettenis@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: m...@cvs.openbsd.org2021/12/28 06:16:28 Modified files: sys/uvm: uvm_fault.c Log message: Unlock bottom part of the fault handler. Tested by many during the past months, thanks! ok sthen@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: clau...@cvs.openbsd.org 2021/12/28 04:59:48 Modified files: usr.bin/rsync : io.c Log message: In io_write_buf() adjust the calculation of the multiplex message size so that the loop works even for buffers bigger than 0xff. The code does not produce such big buffers but better make the code correct. Reported by Blago Dachev (blago (at) dachev (dot) com) OK benno@
