virtio: Fix condition for buffer chaining, negotiate VIRTIO_F_ANY_LAYOUT
In 0.9-only time, the VIO_HAVE_MRG_RXBUF macro checked just for the
VIRTIO_NET_F_MRG_RXBUF feature. The meaning was later changed to
(version_1 || VIRTIO_NET_F_MRG_RXBUF), but the new meaning is only
correct for one use of the macro. The buffer chaining must check for the
MRG_RXBUF feature exclusively.
On the other hand, the check if we have to split the header from the
rest of the buffer in the rx queue is a workaround for old kvm versions.
The standard has since then gained the ANY_LAYOUT feature flag to turn
off this workaround. According to the virtio 1.x standard, we should
accept VIRTIO_F_ANY_LAYOUT if it is offered for transitional devices.
ANY_LAYOUT is implicit if VERSION_1 has been negotiated.
Since accepting ANY_LAYOUT only relaxes the requirements for us, we can
simply accept it globally for all virtio device types. vioblk(4) and
vioscsi(4) unconditionally use the strict buffer layout required for
legacy devices without ANY_LAYOUT, anyway.
[4 lines not shown]
Inherit the DMA tag from the device itself and only override what
is necessary. Whether a device is DMA coherent or not depends on
the device, the SMMU does not influence DMA coherency attributes.
I assume we have been lucky so far that our machines that have an
SMMUv2 usually have devices with DMA coherency. On the RK3588
this is not the case, and us always adding the COHERENT flag makes
devices fail to work when used with smmu(4) enabled.
ok kettenis@
regression tests for certificates with empty principals sections
(which are now unconditionally refused) and for certificates with
wildcard principals (which should only be accepted in host certs)
When certificate support was added to OpenSSH, certificates were
originally specified to represent any principal if the principals
list was empty.
This was, in retrospect, a mistake as it created a fail-open
situation if a CA could be convinced to accidentally sign a
certificate with no principals. This actually happened in a 3rd-
party CA product (CVE-2024-7594).
Somewhat fortunately, the main pathway for using certificates in
sshd (TrustedUserCAKeys) never supported empty-principals
certificates, so the blast radius of such mistakes was
substantially reduced.
This change removes this footcannon and requires all certificates
include principals sections. It also fixes interpretation of
wildcard principals, and properly enables them for host
certificates only.
[4 lines not shown]
Don't misuse the sftp limits extension's open-handles field.
This value is supposed to be the number of handles a server will allow
to be opened and not a number of outstanding read/write requests
that can be sent during an upload/download.
ok markus@
add a "ssh -O channels user at host" multiplexing command to get a
running mux process to show information about what channels are
currently open; ok dtucker@ markus@
X509_NAME_ENTRY_set_data: remove V_ASN1_APP_CHOOSE quirk
This is the last remaining actual use of ASN1_PRINTABLE_type(), which will
go away in the next major bump.
ok kenjiro
conf_api: remove CONF_DEBUG and disabling of assert()
The only thing CONF_DEBUG has done in ages is defining NDEBUG in a file
that does not contain a single assert. Kill it.
ok jsing kenjiro
relayd: fix relay_http_time() to emit GMT times again
The HTTP standard RFC 9110 requires GMT, in HTTP-date. We used to do this
until a recent modification to localtime.c changed GMT to UTC.
sync from httpd
Reimplement ASN1_PRINTABLE_type() dance in ca.c
In ca.c, there is some minimal validation of strings in the subject of
a certificate. ASN1_PRINTABLE_type() is silly API that only exists for
this one call. I want to remove a_print.c in the next major bump.
ASN1_PRINTABLE_type() returns V_ASN1_PRINTABLESTRING if all characters
belong to the specific subset of ASCII listed in X.680, 41.4, Table 10.
Otherwise it returns V_ASN1_T61STRING or V_ASN1_IA5STRING depending on
whether there is a character with the high bit set or not.
With this in mind, the logic in ca.c comes down to this: blindly allow
UTF-8, BMP and T61 strings. All other strings get rejected if the high
bit of some character is set, or if the string is printable and there
is a non-printable character.
ok jsing kenjiro
httpd: fix server_http_time() to emit GMT times again
The HTTP standard RFC 9110 requires GMT, in HTTP-date. We used to do this
until a recent change to localtime.c changed GMT to UTC.
From Sören Tempel, ok sthen
