Remove imsg_get() and imsg_compose_ibuf() from the imsg API.
While doing so add the following functions:
- imsg_add_strbuf
a wrapper for ibuf_add_strbuf similar to imsg_add it uses the
imsg namespace. It feels more natural to use imsg_add and
imsg_add_strbuf to construct messages (mixing imsg_add and ibuf_add_xyz
seems strange).
- imsgbuf_get_userdata & imsgbuf_set_userdata
- imsgbuf_set_close_callback
These three functions are used to replace the bad imsgev wrappers in
various deamons. It actually allows one to use the imsg API directly
in libevent code.
- msgbuf_readlen
return how many messages are ready to be processed on a msgbuf.
This can be used to implement a back pressure mechanism for individual
msgbuf sockets.
[2 lines not shown]
Improve suspend/resume support such that it restores the configuration
of pins used as interrupts. Needed for hibernate support on arm64.
ok deraadt@, jca@, mglocker@
Test both types of empty data lines (empty text line and empty request line)
in both layout contexts (data layout line and horizontal line layout line),
making sure that tbl_data.c rev. 1.48 handles all code paths in tbl_data()
correctly.
When a text line in tbl(7) data is completely empty (""),
do not access the byte beyond the terminating NUL byte.
Instead, generate an empty span that contains no data cells,
optionally preceded by a horizontal line if requested by the layout.
This buffer overrun reading exactly one byte too far usually had
no adverse consequences. No matter the value of the wrongfully read
byte, the code would correctly continue after the "if" block,
either (more likely) via failing the p[1] == '\0' condition
or (less likely) via the default branch of the switch.
Theoretically, it might segfault on the one-byte access, though.
Patch from Hippolyte d'Oncieu de la Batie <hippolyte.doncieu at gmail.com>
who found this bug using clang-14 with libFuzzer and AddressSanitizer.
Reported via espie@.
Clarifying source code comment by me.
pf(4) is still overly strict in filtering MLD messages
pf(4) may drop valid Multicast Level Discovery (MLD) packet
with unspecified source address. According to RFC 3590,
section 4, Source Selection Guidelines, MLD Report and
MLD Done messages may be carried by IPv6 datagrams with
unspecified source address.
Issue reported and patch kindly submitted
by Kristof Provost (kp _at_ FreeBSD _dot_ org)
OK bluhm@
pax: Ensure when removing ".." path components extra slashes are also
removed.
A specially constructed archive could trick pax into extracting outside
of the working directory. This also fixes a string ending in a compoment
of exactly ".." reading one past the NUL.
ok millert@
extend the "mcast" pledge to allow multicast tweaks on ethernet frame sockets.
this is for lldpd, which wants to receive lldp packets sent to a
multicast address on interfaces as they attach at runtime, which
currently isn't allowed by pledge.
part of a bigger diff that was ok deraadt@
tighten pledge_sockopt()s level/optname checks for different types of sockets
tl;dr: the meaning of the setsockopt and getsockopt level and optname
arguments are dependent on the type of the socket you're working
with, they can't be safely understood without knowing the address
family and protocol.
i think we've been able to ignore to socket address family and
protocol so far by luck, particularly because openbsd (henning)
removed a bunch of address families like AF_IPX and AF_NETATALK.
like AF_INET and AF_INET6, they use values from the wire protocol
as identifiers in the ABI, particularly sub protocol numbers like
IPPROTO_TCP. there's no guarantee these numbers don't overlap with
a protocol from another address family. netipx used IPXPROTO_SPX
like how AF_INET uses IPPROTO_IP, but it's only luck that their
values don't collide with each other or another protocol. this
principle applies to all socktypes though.
this is also reflected in the way sockopts are handled by protocol
[17 lines not shown]
Compose a new imsg when relaying terminate to vmd(8) control.
Instead of forwarding the imsg, which was already consumed in the
parent vmd process, compose a new one to the control process. When
vmd was refactored to use the new imsg api for consuming the payload
instead of reading directly from the underlying ibuf, it caused
proc_forward_imsg() to forward incomplete data.
Instead of mucking about with the underlying ibuf and rewinding it,
update the only case of the consume-then-forward pattern to compose
a new imsg by using proc_compose_imsg().
Original diff and issue from Nick Owens.
rpki-client: remove another layer in the cms code
The cms_parse_validate() -> _internal() split was done for detached
messages, i.e., geofeed. This has been retired for a while now, and
won't come back.
ok claudio
vmm(4): support variable length instructions in VMX paths.
The Intel VMX handlers for things like HLT, RDMSR, etc. perform
strict checks for instruction length. This is excessive and incorrect
given the joys of x86/amd64. There's no need to kill the vcpu if
it was silly enough to prefix a HLT for some strange reason.
"sure", mlarkin@
rpki-client: garbage collect the _parse() functions
The _parse() functions are no longer used and can be removed.
With them gone, cms_parse_validate() becomes internal to cms.c
ok claudio
rpki-client: replace _parse() functions for signed objects
Replace calls to _parse() with calls to signed_object_parse() both
in file mode and in the parser process.
ok claudio
