| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Skip cameracaptured's GPU prewarm on the paravirtual Metal driver On an iPadOS 26.6.2 iPad Pro guest cameracaptured crashed at every boot (KERN_INVALID_ADDRESS at 0xc in -[NRFProcessorV3 prewarm] -> -[ToneMappingCurves initWithWithContext:] -> the Metal driver), launchd throttled its restarts, and every process that first touched AVCapture blocked in a synchronous XPC to it. SpringBoard's main thread froze that way as soon as an app started recording. The fault is in the cloudOS 26.4 AppleParavirtGPUMetalIOGPUFamily, not in the sandbox gate on the GPU's user client. ToneMappingCurves fills textures made from a shared MTLHeap with -replaceRegion:. The driver keeps a texture's CPU layout in AppleParavirtTexture's _dimension. Every initialiser sets it except -initWithHeap:resource:offset:length:descriptor:, which heap textures use, and -replaceRegion: reads it without a check. The daemon does have a Metal device: the preload returns early without a command queue, and the faulting frame is a real AppleParavirtTexture. So kernel-exp-paravirt_user_clients would not help, and the hook does not depend on it. libvcamcaptured now replaces the daemon's one call to PrewarmThreadSafeSBPs with a NOP from its constructor, when the paravirtual driver is installed. Prewarming only compiles shaders before first use, and nothing waits on that function. The rest of the preload is kept: the processor flags, the data migration, and the deferred shader cache copy, whose semaphore deferred processing waits on for up to 180 s. The call is found from the exported FigCapturePreloadShaders through its branch, the one pacia-signed block invoke, and the block's one call of its captured command queue into CMCapture's __text. Over the real bytes this gives 0x1aeb2fd68 on 23G90 and 0x1b0759d10 on 24A435. Any mismatch leaves the prewarm in place and logs the failed step. The scan is plain C, so make test-vcam-prewarm runs it on the host against a synthetic stream with the decoys those builds have. Research/Guest/gpu_acceleration.md records the driver bug, how to find it in a driver, and what to check on a guest. Row 22 of the CFW table in Research/0_binary_patch_comparison.md lists the hook. This also corrects the reasoning #562 gave for turning the paravirtual user-client allowlist on in standard: cameracaptured already has a Metal device and dies on the heap-texture bug, which that gate does not touch. The allowlist stays on for daemons and tools that want the GPU (#22); gpu_acceleration.md and the comparison note now say so. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 5 天前 | |
Deliver VM location through guest app hook Publish validated location state to authorized CoreLocation clients, keep guest hooks in sync, and add a Release artifact workflow for unsigned CI packages. | 14 天前 | |
chore: tidy the github action workflow | 14 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 5 天前 | ||
| 14 天前 | ||
| 14 天前 |