AES_set_encrypt_key zeroed the whole schedule and set rounds before it
checked the key length, so a refused call changed the AES_KEY. As in
LibreSSL 2.5.4's aes_core.c, it now returns -1 or -2 before writing
anything and writes only the 44, 52 or 60 words the key length needs.
The test fills the key with a sentinel and checks, for both setup
functions, that refused calls leave all 244 bytes unchanged, that
AES-128 and AES-192 keep the 16 and 8 unused words, and that every
written word matches the FIPS-197 appendix A schedules and the
decryption schedules computed independently and with OpenSSL 3.0.13.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Copy the source array into this and return this, as the console does
(measured on a PS4 Pro, firmware 10.71). Knowledge is Power: Decades
imports it; the inventory stub threw NotImplemented.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
AES_set_encrypt_key, AES_set_decrypt_key, AES_encrypt, AES_decrypt,
AES_ecb_encrypt, AES_cbc_encrypt, AES_cfb128_encrypt and
AES_ctr128_encrypt threw. They now follow LibreSSL's aes.h and its CBC,
CFB-128 and CTR mode code on the caller's 244-byte AES_KEY: key setup
returns -1 for null arguments and -2 for a key length other than 128,
192 or 256 bits, CBC pads a partial final block with the IV and writes
the whole block, CFB and CTR resume from *num, and the CTR counter
carries across all 128 bits.
The test checks the FIPS-197 appendix A and C vectors and the SP 800-38A
CBC, CFB-128 and CTR vectors, split across calls, in place and with
partial blocks.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The shader float mode entry said "Other f64 arithmetic does not model
these denormal controls". On main, v_add_f64, v_mul_f64, v_floor_f64,
v_ceil_f64, v_fract_f64, v_frexp_mant_f64, v_frexp_exp_i32_f64,
v_div_fixup_f64, the f64 compares and ds_min/max/cmpst_f64 read the
f16/f64 denormal field, and each has its own entry. The sentence now
names the f64 arithmetic whose translation still does not read it.
The v_floor_f64 entry said its modifier run used 16 of the 23 measured
values. The run's list holds 13 of them plus -1.5, 2.75 and 1 - 2^-53.
Co-Authored-By: Claude <[email protected]>
The recompiler orders an LDS atomic, and the compare-exchange loop that
writes a byte or a halfword of LDS (ds_write_b8/b16), with a
workgroup-scope OpMemoryBarrier after the update. AMD's proprietary
Windows driver 32.0.21042.62 (Radeon 0x13c0, RDNA 2) compiles that
memory barrier to s_barrier, as the code objects in its pipeline cache
show. Such updates usually sit in branches that only some waves of a
workgroup take, so those waves execute extra s_barriers, which pair
with the other waves' barriers, and the other waves read LDS before it
is written. An OpMemoryBarrier is not an execution barrier and SPIR-V
allows it in non-uniform control flow, so the SPIR-V is valid; a
device-scope OpMemoryBarrier compiles to GL0 and GL1 cache
invalidations without s_barrier there.
PS5LM Plus (PPSA99581, llama.cpp's Vulkan backend) drifted into
garbage on that driver with flash attention on. Its flash-attention
shader stores two halfwords to LDS in a branch that two of its four
waves take, inside the KV loop. The driver's code had 23 s_barrier for
the guest's 21; a replay of the dispatch differed from NVIDIA in 159
words, up to 1.7e38, and now has 21 and differs only in the last bit
of 9 words.
On that driver the fence is now device scope, which orders everything
the workgroup-scope fence did. Other drivers keep the workgroup scope.
The flag is part of the shader cache key, and agc_shader_replay takes
--device-scope-lds-memory-barriers to replay a request the way that
driver compiles it. The LDS update helper already fences, so the
second, identical fence after it in ds_min/max_f32 and the other
read-modify-write LDS operations is dropped.
agc_driver_lds_subword_store_branch stores a halfword to LDS in a
branch that waves 0-1 of four take, delays those waves and then
exchanges LDS slots across one s_barrier. Before, thread 64 read a
stale slot on the AMD driver; it passes on AMD and NVIDIA now.
agc_subgroup_barrier checks the driver quirk and that ds_write_b16,
ds_add_u32 and ds_max_f32 each emit one fence of the expected scope.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BM2kfDbr6MydxsfTckZJDR
Implement sceCesUcsProfileInitEucJpX0208, sceCesUcsProfileInitEucJpX0208Ss2,
sceCesUcsProfileInitEucJpX0208Ss2Ss3 and sceCesUcsProfileInitSJis1997X0208.
The JIS X 0208 table is JIS0208.TXT, derived from the CP932 table without
rows 13 and 89-92 and with six cells changed. The EUC-JP variants add SS2
half-width katakana and SS3 JIS X 0212 as their names say. Cell 0x2140 and
the Shift-JIS single bytes 0x5C and 0x7E, where the sources disagree, throw.
The libc.prx that PS4 titles ship (measured for CUSA04865 and CUSA12435 on a
PS4 Pro, firmware 10.71) names 0 "No error", 1 to 94 with the FreeBSD texts
(30 is "Read-only filesystem"), answers every other number, 95 and 96
included, with "error_code=0x%08x", and leaves errno alone. AnyPS5 returned
"No error: 0", named 95 and 96, answered "Unknown error: %d" and set errno
to 22. strerror_r and perror keep their wording; only the shared EROFS text
changes for them.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
