CVS: cvs.openbsd.org: src

2024-01-30 Thread Theo Buehler
CVSROOT:/cvs
Module name:src
Changes by: t...@cvs.openbsd.org2024/01/30 23:57:21

Modified files:
usr.sbin/rpki-client: extern.h mft.c parser.c 

Log message:
Introduce and use mft_compare_issued()

Newly issued manifests should not only have a higher manifestNumber,
their issuance time should also be later. Add corresponding checks
and warnings when comparing a newly fetched manifest to a manifest
from the cache.

ok job (who noticed that such a check was missing)



CVS: cvs.openbsd.org: src

2024-01-30 Thread Theo Buehler
CVSROOT:/cvs
Module name:src
Changes by: t...@cvs.openbsd.org2024/01/30 23:54:43

Modified files:
usr.sbin/rpki-client: extern.h mft.c parser.c 

Log message:
Rename mft_compare() to mft_compare_seqnum()

This makes it clearer what exactly this function compares. Also drop some
NULL checks that made the semantics of this function tricky.

ok job



CVS: cvs.openbsd.org: src

2024-01-30 Thread Theo Buehler
CVSROOT:/cvs
Module name:src
Changes by: t...@cvs.openbsd.org2024/01/30 23:53:21

Modified files:
usr.sbin/rpki-client: parser.c 

Log message:
Pull mft comparison into proc_parser_mft_pre()

This way we can be sure more easily that both manifests are non-NULL,
thus avoiding some NULL checks and risk of use-after-free. This also
makes it clearer which manifest is the "older" one and will simplify
an upcoming commit doing issuance time comparison.

This adds a bit of a hack to proc_parser_mft_pre() to ensure we don't
look into DIR_TEMP in noop mode.

ok job



CVS: cvs.openbsd.org: src

2024-01-30 Thread Jason McIntyre
CVSROOT:/cvs
Module name:src
Changes by: j...@cvs.openbsd.org2024/01/30 23:50:16

Modified files:
share/man/man4 : pfsync.4 

Log message:
the maxupd example was removed in -r.1.15, so do not refer to it;
from janne johansson

with that removal the surrounding text becomes simpler, so trim it;



CVS: cvs.openbsd.org: src

2024-01-30 Thread Theo Buehler
CVSROOT:/cvs
Module name:src
Changes by: t...@cvs.openbsd.org2024/01/30 23:48:27

Modified files:
usr.sbin/rpki-client: parser.c 

Log message:
proc_parser_mft_pre: move freeing into an error path

Simplifies subsequent commits which will use the same exit path.

ok job



CVS: cvs.openbsd.org: src

2024-01-30 Thread Theo Buehler
CVSROOT:/cvs
Module name:src
Changes by: t...@cvs.openbsd.org2024/01/30 23:46:31

Modified files:
usr.sbin/rpki-client: parser.c 

Log message:
proc_parser_mft: fix overloading of error

parser.c r1.101 switched the meaning of mft1 and mft2, but did not
fix up the overloading of the error from the temporary file if both
are set.

ok job



CVS: cvs.openbsd.org: src

2024-01-30 Thread Philip Guenther
CVSROOT:/cvs
Module name:src
Changes by: guent...@cvs.openbsd.org2024/01/30 23:06:28

Modified files:
sys/arch/amd64/amd64: trap.c 
sys/arch/amd64/include: frame.h 
gnu/usr.bin/binutils/gdb: amd64obsd-tdep.c 

Log message:
Swap the r10 and rcx registers in the amd64 trapframe so that the
first six entries are in the same order as syscall arguments, such
that syscall() can just use the trapframe as the argument vector
for mi_syscall() and not need to reorder into another buffer on the
stack.  This doesn't affect coredump layout or ptrace(2), but does
affect kernel crash dumps.

Possibility noted during miod@'s cleanup of the MD syscall()
implementations

ok mlarkin@ kurt@



CVS: cvs.openbsd.org: src

2024-01-30 Thread Philip Guenther
CVSROOT:/cvs
Module name:src
Changes by: guent...@cvs.openbsd.org2024/01/30 22:49:33

Modified files:
sys/arch/amd64/amd64: vmm_machdep.c 
sys/arch/amd64/include: cpufunc.h 

Log message:
Make wrpkru() consistent with rdpkru() by passing ecx as an argument.

ok mlarkin@



CVS: cvs.openbsd.org: src

2024-01-30 Thread James Hastings
CVSROOT:/cvs
Module name:src
Changes by: hasti...@cvs.openbsd.org2024/01/30 18:01:11

Modified files:
sys/dev/fdt: com_fdt.c 

Log message:
add MediaTek UART support.

ok kettenis@



CVS: cvs.openbsd.org: src

2024-01-30 Thread Dave Voutila
CVSROOT:/cvs
Module name:src
Changes by: d...@cvs.openbsd.org2024/01/30 16:01:49

Modified files:
usr.sbin/vmd   : vionet.c virtio.h 

Log message:
Rewrite vmd(8)'s vionet to be zero-copy.

Similar to the rewrite of the virtio block device to use zero-copy
semantics, this rewrites how the virtio network device works with
the virtqueue ring buffers to minimize data copying. For guests
that don't use the built-in DNS and mac filtering capabilities,
data can now be transfered to/from the virtqueue and the tap(4)
directly without temporary buffers.

A lot of the virtio semantics are cleaned up as well, including
proper error states.

Tested with help by mbuhl@, friehm@, mlarkin@, and others.

"go for it," mlarkin@



CVS: cvs.openbsd.org: src

2024-01-30 Thread Theo Buehler
CVSROOT:/cvs
Module name:src
Changes by: t...@cvs.openbsd.org2024/01/30 10:43:39

Modified files:
lib/libcrypto/cmac: cmac.c 

Log message:
Remove now unnecessary NULL check before EVP_CIPHER_CTX_cleanup()



CVS: cvs.openbsd.org: src

2024-01-30 Thread Theo Buehler
CVSROOT:/cvs
Module name:src
Changes by: t...@cvs.openbsd.org2024/01/30 10:41:01

Modified files:
lib/libcrypto/evp: evp_cipher.c evp_digest.c 

Log message:
Make EVP_{CIPHER,MD}_CTX_{cleanup,reset}() NULL-safe

We have a bunch of code that relies on this. Surely there is code out
there in the wider ecosystem that relies on these being NULL-safe by
now since upstream sprinkles NULL checks wherever they can.

ok beck joshua



CVS: cvs.openbsd.org: src

2024-01-30 Thread Theo de Raadt
CVSROOT:/cvs
Module name:src
Changes by: dera...@cvs.openbsd.org 2024/01/30 09:43:22

Modified files:
sys/arch/macppc/include: vmparam.h 

Log message:
the clang binary never shrinks, especially since it is statically
linked (for performance).  in this case, it grew larger than the
maximum text segment size; increase that size.



CVS: cvs.openbsd.org: src

2024-01-30 Thread Stefan Sperling
CVSROOT:/cvs
Module name:src
Changes by: s...@cvs.openbsd.org2024/01/30 08:33:32

Modified files:
sys/dev/ic : qwx.c 

Log message:
enable qwx "ext" IRQs for data packets once we have moved into RUN state



CVS: cvs.openbsd.org: src

2024-01-30 Thread Stefan Sperling
CVSROOT:/cvs
Module name:src
Changes by: s...@cvs.openbsd.org2024/01/30 08:32:04

Modified files:
sys/dev/ic : qwx.c qwxreg.h qwxvar.h 

Log message:
set up qwx REO ring routing



CVS: cvs.openbsd.org: src

2024-01-30 Thread Stefan Sperling
CVSROOT:/cvs
Module name:src
Changes by: s...@cvs.openbsd.org2024/01/30 08:30:13

Modified files:
sys/dev/ic : qwx.c 

Log message:
fix qwx_core_pdev_create() to not drop into its error path on success

Otherwise we free rings that were just allocated, causing mbuf corruption.



CVS: cvs.openbsd.org: src

2024-01-30 Thread Joel Sing
CVSROOT:/cvs
Module name:src
Changes by: js...@cvs.openbsd.org   2024/01/30 07:50:50

Modified files:
lib/libssl : tls13_legacy.c 

Log message:
Restore SSL_shutdown() two step sequence.

Change SSL_shutdown() such that it will return 0 after sending a
close-notify, before potentially returning 1 (indicating that a
close-notify has been sent and received) on a subsequent call. Some
software depends on this behaviour, even though there are cases where
the first call could immediately return 1 (for example, when the peer
has already sent a close-notify prior to SSL_shutdown() being called).

ok tb@



CVS: cvs.openbsd.org: src

2024-01-30 Thread Joel Sing
CVSROOT:/cvs
Module name:src
Changes by: js...@cvs.openbsd.org   2024/01/30 07:46:46

Modified files:
regress/lib/libssl/shutdown: shutdowntest.c 

Log message:
Add a shutdown sequence regress test.

Some software relies on SSL_shutdown() returning 0 (indicating close-notify
sent) before returning 1 on a subsequent call (indicating close-notify sent
and received). It is worth noting that there is no guarantee that this will
occur in normal operation, as the peer could send a close-notify prior to
SSL_shutdown() being called.

This is currently failing for TLSv1.3.



CVS: cvs.openbsd.org: src

2024-01-30 Thread Claudio Jeker
CVSROOT:/cvs
Module name:src
Changes by: clau...@cvs.openbsd.org 2024/01/30 06:51:13

Modified files:
usr.sbin/bgpctl: bgpctl.c bgpctl.h output.c output_json.c 

Log message:
Adjust bgpctl to work with the modified aspath functions from util.c

While doing that convert IMSG_CTL_SHOW_RIB over to the new ibuf api.
OK tb@



CVS: cvs.openbsd.org: src

2024-01-30 Thread Claudio Jeker
CVSROOT:/cvs
Module name:src
Changes by: clau...@cvs.openbsd.org 2024/01/30 06:50:09

Modified files:
usr.sbin/bgpd  : bgpd.h rde.c util.c 

Log message:
Convert he ATTR_ASPATH and ATTR_AS4_PATH handlers in rde_attr_parse()
to new ibuf API.

Various aspath functions are modified to work better with ibufs.
aspath_inflate() now only works with ibufs and is a lot simpler.
aspath_verify() does all the checks using the ibuf api and therefor
most length checks can be skipped.
aspath_asprint() and the new internal aspath_strsize() and aspath_snprint()
are totally overhauled -- including some bugs that got squashed.
OK tb@



CVS: cvs.openbsd.org: src

2024-01-30 Thread Claudio Jeker
CVSROOT:/cvs
Module name:src
Changes by: clau...@cvs.openbsd.org 2024/01/30 04:15:05

Modified files:
usr.sbin/rpki-client: http.c 

Log message:
In the previous commit idle connections are reinserted onto the active list
when the connection is closed. Since active connections are processed after
idle ones this will trigger a "timeout, connection closed" warning.
Work around this by clearing io_time in the close case of idle connections
and checking for this in the active connection case.
Problem noticed and OK job@



CVS: cvs.openbsd.org: src

2024-01-30 Thread Claudio Jeker
CVSROOT:/cvs
Module name:src
Changes by: clau...@cvs.openbsd.org 2024/01/30 03:16:13

Modified files:
usr.sbin/rpki-client: http.c 

Log message:
Fix a race between scheduling a new request onto an idle connection and
closing the same connection.

When closing an idle connection that connection needs to be moved off the
idle queue and back onto the active queue. Do this in the two possible
cases (directly in http_close() and in http_handle() for the STATE_IDLE
case). In both cases it is possible that the system needs to repoll the
connection and while waiting a request could be scheduled on that connection
if it remains on the idle queue.

Problem hit by job@
OK tb@