Some new intel machines have a new 3rd tier of cpus called LP-E which are
E-core (Atom) without L3 cache. These cpus are Lethargic, and it sucks
when processes migrate to them.
This introduces sysctl hw.blockcpu= which takes a sequence of 4 letters.
S (for SMT), P (regular performance cpu), E (efficient cpu) generally
80% to 50% as fast), and L (lethargic cpu) which are even slower.
By setting this, you can select cpus to kick out of the scheduler. The
default is SL.
The hw.smt sysctl remains for now but we will eventually delete it.
hw.smt changes and follows hw.blockcpu=S.
ok kettenis mlarkin
Fix an off-by-one error in the X.509 verifier depth checking.
In x509_verify_build_chains(), ensure that we check the current depth
against max_depth prior to turning it into a legacy-style depth index.
Additionally, add a guard to x509_verify_chain_append() so that we avoid
exceeding the maximum certs per chain, even if we fail to handle this
correctly elsewhere. Also prevent the legacy callback from being able
to override the maximum verification depth.
The current off-by-one allows for a 4 byte overwrite to occur on heap
allocated memory - this will likely trigger a crash on OpenBSD (but may
go unnoticed elsewhere). This is only reachable if a TLS client is talking
to a malicious server or if a TLS server has client certificate
verification enabled - in both cases the verification depth also needs to
be set to the maximum allowed value of 32.
It is worth noting that many TLS clients/servers set the maximum
verification depth to a value that is much less than the default. A libtls
client or server uses a default depth of 6 and is not impacted in this
[6 lines not shown]
Reorganize structure of key_code so that it can be built directly by
bitshifts rather than a load of huge switches, from Dane Jensen in
GitHub issue 4953.
access ida under spltty()
ida is accessed from both process and interrupt contexts.
The interrupt context use occurs when a fence is hardware signaled:
dma_fence_signal -> amdgpu_pasid_free_cb -> ida_free -> idr_remove
linux currently uses an xarray with XA_FLAGS_LOCK_IRQ for ida, which
blocks interrupts when locked
This change was prompted by protection faults such as:
idr_tree_SPLAY+0x58
idr_alloc+0xb1
amdgpu_pasid_alloc+0x5d
amdgpu_driver_open_kms+0xac
drm_file_alloc+0x245
drmopen+0x12c
seen with 6.12 and 6.18 drm
[5 lines not shown]
sys/net80211: announce 160MHz channels only when driver supports it
Support of 160Mhz window brings a regression for drivers which do not
supprot 160MHz window which leads to the wrong channel center.
It was tested on iwx with and without 160Mhz window support in the code
agaisnt 2.4Ghz network with 20Mhz and 40Mhz, and 5Ghz with 40Mhz, 60Mhz,
80Mhz and 160Mhz window.
Reported as iwm issue by martijn@
OK: stsp@
When in copy mode with a large scroll offset and the window is resized
so that history shrinks, data->oy can exceed screen_hsize causing an
unsigned integer underflow in the py computation. Clamp data->oy in
window_copy_resize and window_copy_cmd_refresh_from_pane before the
subtraction. From futpib at gmail dot com in GitHub issue 4958.
apply the same validity rules to usernames and hostnames set for
ProxyJump/-J on the commandline as we do for destination user/host
names.
Specifically, they are no longer allowed to contain most characters
that have special meaning for common shells. Special characters are
still allowed in ProxyJump commands that are specified in the config
files.
This _reduces_ the chance that shell characters from a hostile -J
option from ending up in a shell execution context.
Don't pass untrusted stuff to the ssh commandline, it's not intended
to be a security boundary. We try to make it safe where we can, but
we can't make guarantees, because we can't know the parsing rules
and special characters for all the shells in the world, nor can we
know what the user does with this data in their ssh_config wrt
percent expansion, LocalCommand, match exec, etc.
[4 lines not shown]
libssl regress: adjust golden numbers for RSASSA-PSS
Add the three RSASSA-PSS SignatureScheme 0x080b, 0x080a, 0x0809 in the
appropriate spots in (components of) the ClientHello and adjust various
length octets by adding 6.
libssl: announce support for RSASSA-PSS signature schemes
Announce the signature schemes for RSASSA-PSS with pubkey OID RSASSA-PSS
between RSASSA-PSS with pubkey OID rsaEncryption and RSASSA-PKCS1-v1_5.
This is the last step in the everlasting saga for making these signature
schemes and certificates with RSASSA-PSS OID work. Fortunately, these are
rarely used since they are extremely complex and inefficient also due to
the large size of the parameters. This addresses bug reports by Steffen
Ullrich and Tom Lane.
Tested by bluhm.
ok djm jsing kenjiro
ssl_sigalg_pkey_ok: allow RSASSA-PSS with pubkey OID RSASSA-PSS
This fixes a long-standing logic error that hasn't been noticed because
we never announced the rsa_pss_pss_sha{256,384,512} SignatureScheme. The
EVP_PKEY_id() of a RSA-PSS pubkey is EVP_PKEY_RSA_PSS, not EVP_PKEY_RSA.
Thanks to beck for helping me figure out how to fix this correctly. It
drove me nuts for a very long time. Problem also noticed by Tom Lane
due to some PostgreSQL regress failures.
ok djm jsing kenjiro
Improve OpenBSD::Unveil POD
The choice of variable names made it somewhat unclear what arguments
to pass and made it seem the interface might differ from unveil(2).
ok dgl@
Remove useless memory barriers in igmp and mld6 timer.
Multicast timers are protected by poper locks. The shortcut that
avoids locking when no timers are scheduled, does not need an
additional membar.
OK mvs@
sys/tmpfs: use getnanotime() like FFS and MFS
Editing files on tmpfs uses nanotime() to update mtime, and touch uses
utimensat(UTIME_NOW) which uses getnanotime() which is cached and which
can be smaller.
So, sed ... A && touch B leads to mtime(A) > mtime(B) which isn't excted.
"Yep" deraadt@
ML-KEM: ensure that key_768 is only dereferenced with 768-bit keys
This looks like a NULL dereference that should crash, but for some reason
it doesn't, even with -O0 with all compilers i tried. At the very least it
may result in compilers deducing that key_768 != NULL and lead to incorrect
optimizations.
ok claudio jsing kenjiro miod
