Failure when using compressed disk

[qmfrederik]

You've mentioned that the ramdisk should be decompressed before being used. That seems to be correct - booting from a ramdisk with compressed files gives the following error:

BSD root: md0, major 3, minor 0
apfs_vfsop_mountroot:2214: apfs: mountroot called!
apfs_vfsop_mount:1777: unable to root from devvp <ptr> (root_device): 2
apfs_vfsop_mountroot:2218: apfs: mountroot failed, error: 2
hfs: mounted AzulD18D52.arm64eCustomerRamDisk on device b(3, 0)
/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-125/Common/ChunkCompression.cpp:604: /usr/lib/dyld: invalid zlib header
Attempting to forcibly halt cpu 1
cpu 1 failed to halt with error -5: halt not supported for this configuration
Debugger synchronization timed out; waited 10000000 nanoseconds
IOPlatformPanicAction -> AppleT8030PMGR
Kernel data abort. at pc 0xfffffff008bcad2c, lr 0xfffffff008bcad24 (saved state: 0xffffffe8162a3040)
          x0: 0x0000000000000000  x1:  0x0000000000000014  x2:  0x0000000000000000  x3:  0x0000000000000000
          x4: 0x0000000000000062  x5:  0x000000023b040000  x6:  0xffffffe8008b1d80  x7:  0x0988fff0078f14f0
          x8: 0xffffffe80ec58048  x9:  0x0000000000000028  x10: 0x00000000fffd8000  x11: 0xffffffe4ce1511d0
          x12: 0x000000007fffffff x13: 0x00000000ffffffff  x14: 0x0000000000000000  x15: 0x0000000000000010
          x16: 0xfffffff0078f1148 x17: 0xfffffff0078f1148  x18: 0x0000000000000001  x19: 0xffffffe800890000
          x20: 0x0000000000088000 x21: 0xffffffe8008b23a0  x22: 0xcda1ffe800890000  x23: 0x000000023b084000
          x24: 0x0000000000084000 x25: 0x000000023d284000  x26: 0x0000000000000001  x27: 0xfffffff13630e910
          x28: 0xfffffff009aa8000 fp:  0xffffffe8162a33d0  lr:  0xfffffff008bcad24  sp:  0xffffffe8162a3390
          pc:  0xfffffff008bcad2c cpsr: 0x204003c4         esr: 0x96000010          far: 0xffffffe80ec58048
panic(cpu 4 caller 0xfffffff007ec6e40): unexpected SIGKILL of init  with reason -- namespace 9 code 0x1 description none

I find the /Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-125/Common/ChunkCompression.cpp:604: /usr/lib/dyld: invalid zlib header error odd.

Do you have any idea why this is raised / how this can be troubleshooted? I know there are version of zlib which are heavily optimized for ARM. Could it be an error in the ARM translation which causes the zlib library to fail?

[TrungNguyen1909]

There are a few variant of this issue

• invalid zlib header
• zlib decode failed
• CS_KILLED of initproc

This issue happens more frequently with HFS+ than APFS.

Even though I haven't succeeded in triaging due to the indeterministic nature of the issue, this is what I'm thinking

• zlib_invalid_header throws before any ARM NEON SIMD code running, which suggests that the issue might be related to some memory copying (?)
• The panic was in kfree_ext, specifically, this line. It happens when z is a null pointer. kfree_ext is called by OSFree_external, which is called by AppleFSCompressionTypeZlib's _decompress routine.
• zlib_decode_failed is throws by actual decompressing code, suggesting either the parser fails to run correctly or the data is corrupted.
• CS_KILLED without any errors thrown suggests a non-fatal error.

[qmfrederik]

Yeah, I briefly looked at this a while ago. My first guess was that perhaps it was an issue with ARM emulation - perhaps an unimplemented instruction - but that didn't yield anything obvious. Plus, an issue in ARM emulation would probably be deterministic.

[TrungNguyen1909]

If an instruction was undefined, the kernel would definitely panic with undefined instruction as the error message.

[TrungNguyen1909]

Just done some tests with ARM NEON with tests taken from arm-neon-tests. Comparing the result with one from an actual iPhone 6S only yields some differences with FMAX, FMIN, FRECPS, FSQRTS with NaN cases, mostly 0x7fc00000(qemu) vs 0xffc00000(actual).

EDIT 1: Also, iOS 12's implementation of AppleFSCompression also uses ARM NEON and it worked properly on Aleph's xnu-qemu-arm64, further suggesting that the issue might not be in AppleFSCompression itself.

EDIT 2: copying a compressed file in the emulated iOS creates a zero-filled file with the same size.

[Neustradamus]

Have you some problems or some patches with zlib?

Please go here to publish patches or problems:

• https://github.com/madler/zlib

[TrungNguyen1909]

@Neustradamus, this is a resolved issue, and the root cause was not related to zlib.