Operand-size-prefixed (0x66) relative branches are classified as having
no branch target, so the AdjustedDelta check never saw them. The
truncated-branch guard only checked whether the branch and its target
move apart, so `66 EB 01 B8 11 22 33 44 C3` rewritten at offset 3 was
accepted and the branch landed in the middle of the new bytes.
Reject a truncated branch whose target is inside the cut, and run that
check for same-length rewrites too, matching the rel8/rel32 path.
oneandonlydean's review of #8457 settled that the guest is modelled as
root, and FreeBSD 11's root keeps the privilege to change a file's
owner, so EPERM for another owner has no source until a console
measurement shows it. chown, lchown and fchownat go back to
RequireGuestOwner after the path lookup, as fchown does, and their debt
entry is main's again. The EPERM assertions go without throw assertions
in their place; the lookup error checks stay.
sigreturn applies FreeBSD 11's amd64 sys_sigreturn checks:
- EFAULT for a null context;
- EINVAL for unknown mc_flags, and for rflags bits outside
PSL_USERCHANGE that differ from the current flags;
- set_fpcontext's FPU format and ownership cases.
It then restores the context through the path setcontext uses, which
now lives in RestoreContext. A non-user %cs and an extended FPU state
still throw.
FreeBSD 11's sys_sched_setscheduler checks: a null parameter is EFAULT,
another process is ESRCH and an unknown policy is EINVAL. Pid 0 sets the
calling thread through scePthreadSetschedparam. Values that call
rejects, and the guest's own pid, whose first thread is not tracked,
still throw.
An owner or group other than the guest's (0) or the unchanged value
returns EPERM after the path lookup, as FreeBSD 11's chown(2) does for
a caller without the superuser privilege. That is the answer #8457
gives for fchown. A lookup error still comes first.
The previous commit replaced the process-wide resolver when a device
was set up after the last deferred device went, so a wrapper returned
for the earlier device, which may still be alive until vkDestroyDevice,
passed through to the later device's loader. The registry now keeps the
resolver of every device it set up and passes each device's calls
through its own one; the most recent resolver is used only for devices
it never set up. Two live devices with different resolvers are still
refused.
MacOsMachOPatcher::Patch discarded its lazyBinding argument, so a
module-free `--macos --lazy-binding` conversion exited 0 and wrote the
same eagerly bound Mach-O as a run without the flag. The Mach-O writer
puts every import in the LC_DYLD_INFO_ONLY bind stream and leaves the
lazy_bind stream empty, with no __la_symbol_ptr or stub helper, so the
macOS target cannot honour the flag. The patcher now throws "macOS
target does not support --lazy-binding", in the form of its
--windows-diagnostics check, so such a conversion exits 2 and writes no
output. Conversions with bundled modules were already refused by the
guest module builder.
Next to CloseWhileWaitingOnFile: 2000 rounds of watching a regular file and replacing its descriptor with dup2 while another thread waits on the queue.
dup2 called EqueueDescriptorClosed(to) while holding the positioned-transfer lock of the descriptor, and the in-flight measurement it waits for needs that lock for its sceKernelLseek, so dup2 onto a watched descriptor deadlocked. The events are removed first, before the lock is taken.
MeasureFiles registered the descriptors it measures in m_measuring and removed them only on the normal path, so an exception between unlocking and relocking left them there and every later RemoveDescriptorEvents for one of them waited forever. Both vectors are reserved before anything is registered, and a guard owns the registration: on every exit it relocks if needed, removes the entries and notifies.
PPSA12361 reaches DB_ALPHA_TO_MASK 0x1aa01 on main 74acfad65b on an RTX 4080 SUPER and an RX 6400. It is the accepted 0xaa01 with bit 16 also set, and radeonsi never programs that combination. Its semantics are not measured, so the path keeps throwing; the entry records it.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
A press published before the keyboard captured the pad stayed in the
read latch and in the sample queue. The first ReadState after the
handoff returned it beside the Intercepted bit, and Read drained the
queued samples from before the capture unmasked. Clear both when a
sample starts the capture, so every read while it lasts holds only the
Intercepted bit.
Found by MarcZX10's review.
Dean