mlkem: clear a few (pointers to) secrets
The ML-KEM code is doing a pretty poor job at cleaning up secrets it no
longer needs. This commit clears a few stack-based arrays containing
secrets or not obviously public information and stack-based structs
containing pointers to secrets.
ok jsing kenjiro
Rename RANK{768,1024} to MLKEM{768,1024}_RANK
RANK768 and RANK1024 are awfully short and generic names for public
constants. Before we make it worse with similarly named constants for
ML-DSA, let's fix this. This follows the naming convention used by the
other macros in the mlkem code.
ok kenjiro jsing
relayd: fix dead store and unindent carp_demote_init
Found by scan-build:
carp.c:64:7: warning: Although the value stored to 'c' is used in the
enclosing expression, the value is never actually read from 'c'
[deadcode.DeadSt ores]
64 | if ((c = carp_group_find(group)) == NULL)
Feedback from Crystal Kolipe and tb@, OK tb@
unifdef m_copypack() use
These ifdefs date back to 1990 in CSRG (SCCS rev 7.20).
m_copypack() never existed in CSRG releases as far as I can tell.
ok deraadt@ mvs@
Remove STABLE_FLAGS_MALLOC
Formerly used by ASN1_STRING_TABLE_{add,cleanup}() which were removed two
years ago. Annotate why STABLE_NO_MASK stays: as usual, security/xca ends
up being the sole consumer of some nonsense. Apparently it needs its own
reimplementation of ASN1_STRING_set_by_NID(), another removable public API
that should never have been exposed.
ok kenjiro
Require SSE in order to use gcm_{gmult,ghash}_4bit_mmx().
Contrary to naming, the '"June" MMX version' of gcm_ghash_4bit_mmx() uses
SSE, while the 'pure-MMX "May" version' does not. This detail got missed
when I was untangling OPENSSL_IA32_SSE2.
Found the hard way by Tate Baldwin and Dennis Camera.
rpki-client: plug a leak in filemode
When displaying an rsync:// uri, filemode would load the file into the
buf pointer which is never freed. Surprisingly, various static analysis
tools fail to notice this.
ok job
Introduce pmap_start_tlb_shoot() from amd64 to make the tlb shootdown
code more similar because a fix is coming and we'd rather place it in
that inline function than replicate it numerous times.
ok kettenis
On Intel CPUs writes to the x2APIC MSRs are non-serializing. This means
that writes done before sending an IPI may not be visible to other CPUs
because of out-of-order execution of the MSR write that triggers the IPI.
Add a "mfence; lfence" barrier like Linux has to prevent this unexpected
trap.
ok deraadt@, mlarkin@, mpi@
Remove bug compatibility for implementations that don't support
rekeying. AFAIK this is only an ancient Sun SSH version.
If such an implementation tries to interoperate with OpenSSH, it
will eventually fail when the transport needs rekeying.
This is probably long enough to use it to download a modern SSH
implementation that lacks this problem :)
ok markus@ deraadt@
Enforce maximum packet/block limit during pre-authentication phase
OpenSSH doesn't support rekeying before authentication completes to
minimise pre-auth attack surface.
Given LoginGraceTime, MaxAuthTries and strict KEX, it would be
difficult to send enough data or packets before authentication
completes to reach a point where rekeying is required, but we'd
prefer it to be completely impossible.
So this applies the default volume/packet rekeying limits to the
pre-auth phase. If these limits are exceeded the connection will
simply be closed.
ok dtucker markus
