Properly set up interrupts in multivec mode if we have multiple msix
vectors but only one queue, making the driver work in uniprocessor
kernels, including RAMDISK.
problem reported by Lexi Winter
ok dlg@
Fix mwx_mcu_send_mbuf() for both mt7925 and mt7921 and the next bit
of 7925 bringup.
mwx_mcu_send_mbuf() handling of the len field was not quite right. Also
implement the mt7925 bits for UNI commands. Fix an issue with the wakeup
of commands, register the command in sc_mcu_wait before enqueuing the
command into the tx queue. Cleanup on error as well.
Implement mt7925_mcu_get_nic_capability() and mt7925_mcu_fw_log_2_host()
with this mwx_mcu_init() is done.
In mwx_dma_txwi_enqueue() use the right len0 value (mt_desc is a pointer).
With this MT7925 prints the mac-address (mwx_mcu_init() succeeds) but
more is needed mwx_init_hardware() after that mwx_preinit() should pass
which is a big step.
For MT7921 it seems this fixes the TX issue I was trying to fix for
so long. Also with this the driver works like before with the new
[3 lines not shown]
Fix up DMA allocation, interrupt handling and early hw init up to
the firmware load sequence.
Rename most functions used in the hw_init and firmware loading path
from mt7921 to mwx since these functions work on all versions now.
This diff allows both 7921 and 7925 devices to load and start the firmware.
Untested are 7920 and 7922 (I lack those devices).
Lots of bits picked up from a diff by mlarkin@
libssl: const correct ssl_*version* API
None of these functions modifies the SSL pointer. An upcoming diff will
need to call one of them with a const pointer, so fix all of them.
ok jsing kenjiro
smtpd was already fork+exec privsep, and starts 6 copies which are
the same binary.
I first decided to random-relink smtpd because of some recent close
calls (in the IPC codepaths, which could have played part in lateral
movement following a primary hole). Then it dawned on me that I can
random relink each of the privsep binaries to be unique, in the same
style as sshd.
Each binary now contains a lot of code it does not need (and is not
reached, but the code remains). That can be refactored as a later
step.
The new /etc/rc relink code will automaticall pick these up.
vague approval martijn, gilles, millert
httpd worries me a bit, so I want to random-relink it at boot.
The new /etc/rc relinking components will automatically pick up this
new directory and process it.
amd64: Place the direct map at a random location
Places the direct map at a 512GB-aligned random location selected from
a 16TB VA window.
With help and suggestions from deraadt@. Tested by many.
add signature malleability and pubkey validity checks to ed25519
verification (SSH doesn't depend on these properties)
Pointed out by Soatok Dreamseeker
Add an explicit-seed variant of the keygen function.
feedback / "looks fine" tb@
relayd: strip Content-Length for chunked messages
RFC 9112 section 6.1 requires an intermediary that forwards a message
carrying Transfer-Encoding to remove any received Content-Length first.
relayd already parses the body as chunked in this case, but previously
left Content-Length in the header tree, so the backend could receive
both framing fields and choose a different message boundary.
When chunked framing is selected, remove Content-Length before header
emission; this preserves relayd's chunked body handling while avoiding
CL.TE ambiguity downstream.
Reproted by: Stuart Thomas
OK: rsaodwski@
httpd: reject CL.TE request framing
RFC 9112 sections 6.1 and 6.3 identify a request containing both
Transfer-Encoding and Content-Length as ambiguous request smuggling
input. httpd is the origin server, not an intermediary, so it should not
rewrite the message and continue processing it.
Reject chunked requests that also carry Content-Length before method
specific body handling or FastCGI parameter generation; this avoids
exposing inconsistent framing metadata to applications.
Reproted by: Stuart Thomas
OK: rsaodwski@
relayd: reject obs-fold to prevent parser differentials (RFC 9112 5.2)
Replace silent kv_extend normalisation with an unconditional reject.
RFC 9112 5.2 permits rejection; it is safer than SP replacement
for a forwarding proxy and handles both request and response direction.
kv_extend is therefore no longer required.
Reported by Stuart Thomas, OK kirill@
httpd: reject obs-fold with 400 (RFC 9112 5.2)
Replace silent kv_extend normalisation with an unconditional 400.
RFC 9112 5.2 explicitly permits rejection; it is the safer choice
over SP replacement, which hides parser ambiguity downstream.
Reported by Stuart Thomas, OK kirill@