Feedback is that it is possible to do this in OpenCore but chances of a successful outcome are low since there are likely multiple kexts linked to
AppleFSCompressionTypeZlib and the OpenCore Block/Insert process would break such links.
com_apple_AppleFSCompression_NoAVXFSCompressionTypeZlib appears in IOService. If it applied correctly, you'll see that and not the original AppleFS Zlib entry.
Doesn’t really make sense that 12.4 would require AVX as Apple Silicon does not support AVX. Strange.
Apple Silicon and Intel are two difference architectures. Apple needs to build binaries containing code for both architectures, which generally makes the binary files twice as large as usual (like back in the PPC/Intel days or the Intel 32 bit/64 bit days). I suppose it would be possible to create a binary that has 4 or 5 architectures (PPC 32/64 bit, Intel 32/64 bit, ARM)
Enabling Voice Control, which would previously fail and trigger the panic, is now possible with the old Zlib kext. This should keep us going until a patch is devised. Thanks!
Interesting thing for the future is that Intel has apparently decided to drop AVX512 instruction support which would leave Apple, unless it decides to release a new Intel Mac with Adler Lake or newer, being able to just continue to use AVX512 until the transition to ARM is completed as the current macs would have support. This would create issues for hackintosh with newer CPUs.
AppleFSCompressionTypeZlib code again. My idea came to nothing, but I did notice something odd (and possibly foreboding): Apple seems to be using all of the YMM registers as arguments. The (pseudocode) sequence of events is:compression_decode_buffer:
(function call)
(function call)
Save all YMM registers on stack
(manipulate those values on the stack)
Restore all YMM registers from (manipulated) stack
returncompression_decode_buffer() is expecting 512 bytes of input in the YMM registers, and is then providing 512 bytes of output in the same YMM registers. This doesn't fit into any of the ABI models I've seen; not only are they using all of the YMM registers (not just the prescribed subset), they seem to be passing an entire buffer therein (and since all of the compression_decode_buffer() arguments seem to be accounted for, it's unclear to me what exactly is being passed via the YMM registers; more analysis is required). (It's also conceivable that they're trying to use the YMM registers as persistent storage, but that makes no sense, since the YMM registers are considered volatile by the ABI (at least the ABI I thought was in use).)compression_decode_buffer() will also use the YMM registers (if only for argument passing), which means there's probably more AVX code lurking out there. If this becomes the norm, patching will become untenable.vmovdqa in compression_decode_buffer(), which means compression_decode_buffer() got called - but that also means the caller didn't previously load the YMM registers with data, because in that case, the #UD would have occurred there instead. I'm now guessing that whatever's calling compression_decode_buffer() is using registers based on what CPUID says is available, but compression_decode_buffer() was compiled to just always use YMM. If you're on an AVX-capable system, this is not an issue, since the caller will see (and use) the YMM registers. On our older systems, the caller is (presumably) using XMM or other registers (or a buffer), but compression_decode_buffer() always tries to use the YMM registers. And having written all of that, I'm now hopeful that a patch might be possible. Maybe tomorrow's shower will be more productive. ;-)AppleFSCompressionTypeZlib kext should have a reasonably high probability of success on a MP5,1 or older, but it should break on any system that natively supports AVX. If someone with an AVX-capable system and time on their hands could test that, I'd love to hear the results.
Same here 4.1 flashed 5.1, 12.4 since last week, not KP or any issues to report!
I just tried activating Voice Control and it failed to dl voice from internet. I am connected. No kp.
_compression_decode_buffer, which contains unfiltered AVX code. The first one, we've previously identified as AppleFSCompressionTypeZlib. The other, AppleDiskImagesUDIFDiskImage, is a plugin for IOHDIXController. The latter seems to be referenced when handling some types of .DMG files._compression_decode_buffer is referenced by parts of the Metal subsystem, numerous dyld_shared libraries, corespeechd (likely the source of the Siri/Voice Control issues), the XPC Services Disk Image Controller, mediaanalysisd, the ContextKit Context Service, some filesystems, and various other subsystems. Also, the unfiltered AVX code in _compression_decode_buffer only gets executed under certain cirumstances; this, along with the number of varied references above, might explain the odd and inconsistent constellation of symptoms we've seen surrounding 12.4.AppleFSCompressionTypeZlib and AppleDiskImagesUDIFDiskImage). It should be inserted into the Kernel/Patch section of your OpenCore config.plist (that's the same section as where the SurPlus patch went). Before anyone points this out, yes - the patches are big and ugly. (They can't all be elegant... ;-) <dict>
<key>Arch</key>
<string>x86_64</string>
<key>Base</key>
<string>_lzvn_decode_buffer</string>
<key>Comment</key>
<string>AVXpel - part 1 of 6</string>
<key>Count</key>
<integer>1</integer>
<key>Enabled</key>
<true/>
<key>Find</key>
<data>
xMF9fwfEwX1/TyDEwX1/V0DEwX1/X2DEwX1/p4AAAADEwX1/r6AAAADEwX1/t8AAAADEwX1/v+AAAADEQX1/hwABAADEQX1/jyABAADEQX1/l0ABAADEQX1/n2ABAADEQX1/p4ABAADEQX1/r6ABAADEQX1/t8ABAADEQX1/v+ABAAA=
</data>
<key>Identifier</key>
<string>com.apple.AppleFSCompression.AppleFSCompressionTypeZlib</string>
<key>Limit</key>
<integer>7168</integer>
<key>Mask</key>
<data>
</data>
<key>MaxKernel</key>
<string>21.5.0</string>
<key>MinKernel</key>
<string>21.5.0</string>
<key>Replace</key>
<data>
ZkEPfwdmQQ9/TxBmQQ9/VyBmQQ9/XzBmQQ9/Z0BmQQ9/b1BmQQ9/d2BmQQ9/f3BmRQ9/h4AAAABmRQ9/j5AAAABmRQ9/l6AAAABmRQ9/n7AAAABmRQ9/p8AAAABmRQ9/r9AAAABmRQ9/t+AAAABmRQ9/v/AAAACQkJCQkJCQkJCQkJA=
</data>
<key>ReplaceMask</key>
<data>
</data>
<key>Skip</key>
<integer>0</integer>
</dict>
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>Base</key>
<string>_lzvn_decode_buffer</string>
<key>Comment</key>
<string>AVXpel - part 2 of 6</string>
<key>Count</key>
<integer>4</integer>
<key>Enabled</key>
<true/>
<key>Find</key>
<data>
xMF9bwfEwX1vTyDEwX1vV0DEwX1vX2DEwX1vp4AAAADEwX1vr6AAAADEwX1vt8AAAADEwX1vv+AAAADEQX1vhwABAADEQX1vjyABAADEQX1vl0ABAADEQX1vn2ABAADEQX1vp4ABAADEQX1vr6ABAADEQX1vt8ABAADEQX1vv+ABAAA=
</data>
<key>Identifier</key>
<string>com.apple.AppleFSCompression.AppleFSCompressionTypeZlib</string>
<key>Limit</key>
<integer>7168</integer>
<key>Mask</key>
<data>
</data>
<key>MaxKernel</key>
<string>21.5.0</string>
<key>MinKernel</key>
<string>21.5.0</string>
<key>Replace</key>
<data>
ZkEPbwdmQQ9vTxBmQQ9vVyBmQQ9vXzBmQQ9vZ0BmQQ9vb1BmQQ9vd2BmQQ9vf3BmRQ9vh4AAAABmRQ9vj5AAAABmRQ9vl6AAAABmRQ9vn7AAAABmRQ9vp8AAAABmRQ9vr9AAAABmRQ9vt+AAAABmRQ9vv/AAAACQkJCQkJCQkJCQkJA=
</data>
<key>ReplaceMask</key>
<data>
</data>
<key>Skip</key>
<integer>0</integer>
</dict>
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>Base</key>
<string>_lzvn_decode_buffer</string>
<key>Comment</key>
<string>AVXpel - part 3 of 6</string>
<key>Count</key>
<integer>2</integer>
<key>Enabled</key>
<true/>
<key>Find</key>
<data>
xf1vAMX9b0ggxf1vUEDF/W9YYMX9b6CAAAAAxf1vqKAAAADF/W+wwAAAAMX9b7jgAAAAxX1vgAABAADFfW+IIAEAAMV9b5BAAQAAxX1vmGABAADFfW+ggAEAAMV9b6igAQAAxX1vsMABAADFfW+44AEAAA==
</data>
<key>Identifier</key>
<string>com.apple.AppleFSCompression.AppleFSCompressionTypeZlib</string>
<key>Limit</key>
<integer>7168</integer>
<key>Mask</key>
<data>
</data>
<key>MaxKernel</key>
<string>21.5.0</string>
<key>MinKernel</key>
<string>21.5.0</string>
<key>Replace</key>
<data>
Zg9vAGYPb0gQZg9vUCBmD29YMGYPb2BAZg9vaFBmD29wYGYPb3hwZkQPb4CAAAAAZkQPb4iQAAAAZkQPb5CgAAAAZkQPb5iwAAAAZkQPb6DAAAAAZkQPb6jQAAAAZkQPb7DgAAAAZkQPb7jwAAAAkJCQkA==
</data>
<key>ReplaceMask</key>
<data>
</data>
<key>Skip</key>
<integer>0</integer>
</dict>
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>Base</key>
<string>_lzbitmap_decode</string>
<key>Comment</key>
<string>AVXpel - part 4 of 6</string>
<key>Count</key>
<integer>1</integer>
<key>Enabled</key>
<true/>
<key>Find</key>
<data>
xMF9fwfEwX1/TyDEwX1/V0DEwX1/X2DEwX1/p4AAAADEwX1/r6AAAADEwX1/t8AAAADEwX1/v+AAAADEQX1/hwABAADEQX1/jyABAADEQX1/l0ABAADEQX1/n2ABAADEQX1/p4ABAADEQX1/r6ABAADEQX1/t8ABAADEQX1/v+ABAAA=
</data>
<key>Identifier</key>
<string>com.apple.driver.DiskImages.UDIFDiskImage</string>
<key>Limit</key>
<integer>7168</integer>
<key>Mask</key>
<data>
</data>
<key>MaxKernel</key>
<string>21.5.0</string>
<key>MinKernel</key>
<string>21.5.0</string>
<key>Replace</key>
<data>
ZkEPfwdmQQ9/TxBmQQ9/VyBmQQ9/XzBmQQ9/Z0BmQQ9/b1BmQQ9/d2BmQQ9/f3BmRQ9/h4AAAABmRQ9/j5AAAABmRQ9/l6AAAABmRQ9/n7AAAABmRQ9/p8AAAABmRQ9/r9AAAABmRQ9/t+AAAABmRQ9/v/AAAACQkJCQkJCQkJCQkJA=
</data>
<key>ReplaceMask</key>
<data>
</data>
<key>Skip</key>
<integer>0</integer>
</dict>
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>Base</key>
<string>_lzbitmap_decode</string>
<key>Comment</key>
<string>AVXpel - part 5 of 6</string>
<key>Count</key>
<integer>4</integer>
<key>Enabled</key>
<true/>
<key>Find</key>
<data>
xMF9bwfEwX1vTyDEwX1vV0DEwX1vX2DEwX1vp4AAAADEwX1vr6AAAADEwX1vt8AAAADEwX1vv+AAAADEQX1vhwABAADEQX1vjyABAADEQX1vl0ABAADEQX1vn2ABAADEQX1vp4ABAADEQX1vr6ABAADEQX1vt8ABAADEQX1vv+ABAAA=
</data>
<key>Identifier</key>
<string>com.apple.driver.DiskImages.UDIFDiskImage</string>
<key>Limit</key>
<integer>7168</integer>
<key>Mask</key>
<data>
</data>
<key>MaxKernel</key>
<string>21.5.0</string>
<key>MinKernel</key>
<string>21.5.0</string>
<key>Replace</key>
<data>
ZkEPbwdmQQ9vTxBmQQ9vVyBmQQ9vXzBmQQ9vZ0BmQQ9vb1BmQQ9vd2BmQQ9vf3BmRQ9vh4AAAABmRQ9vj5AAAABmRQ9vl6AAAABmRQ9vn7AAAABmRQ9vp8AAAABmRQ9vr9AAAABmRQ9vt+AAAABmRQ9vv/AAAACQkJCQkJCQkJCQkJA=
</data>
<key>ReplaceMask</key>
<data>
</data>
<key>Skip</key>
<integer>0</integer>
</dict>
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>Base</key>
<string>_lzbitmap_decode</string>
<key>Comment</key>
<string>AVXpel - part 6 of 6</string>
<key>Count</key>
<integer>2</integer>
<key>Enabled</key>
<true/>
<key>Find</key>
<data>
xf1vAMX9b0ggxf1vUEDF/W9YYMX9b6CAAAAAxf1vqKAAAADF/W+wwAAAAMX9b7jgAAAAxX1vgAABAADFfW+IIAEAAMV9b5BAAQAAxX1vmGABAADFfW+ggAEAAMV9b6igAQAAxX1vsMABAADFfW+44AEAAA==
</data>
<key>Identifier</key>
<string>com.apple.driver.DiskImages.UDIFDiskImage</string>
<key>Limit</key>
<integer>7168</integer>
<key>Mask</key>
<data>
</data>
<key>MaxKernel</key>
<string>21.5.0</string>
<key>MinKernel</key>
<string>21.5.0</string>
<key>Replace</key>
<data>
Zg9vAGYPb0gQZg9vUCBmD29YMGYPb2BAZg9vaFBmD29wYGYPb3hwZkQPb4CAAAAAZkQPb4iQAAAAZkQPb5CgAAAAZkQPb5iwAAAAZkQPb6DAAAAAZkQPb6jQAAAAZkQPb7DgAAAAZkQPb7jwAAAAkJCQkA==
</data>
<key>ReplaceMask</key>
<data>
</data>
<key>Skip</key>
<integer>0</integer>
</dict>plutil -convert xml1 config.plist
Try to put the patches into the Kernel->Patch section (side by side with the SurPlus patches), not directly into the list of kernel extensions ...
Now I see my mistake. Thank you!
I had kernel panic due to AVAST antivirus without "noAVX" kext and Syncretic patch
config.plist capable of booting various versions of Monterey will be littered with these patches (ugh!)._compression_decode_buffer looks at the Zlib strategies in use, and if LZ is involved, it eventually invokes _lzbitmap_decode, which contains unfiltered AVX instructions. As noted earlier, both the AppleFSCompressionTypeZlib and AppleDiskImagesUDIFDiskImage kexts contain apparently-identical copies of _compression_decode_buffer, but the AppleDiskImagesUDIFDiskImage instance contains more public symbols (e.g. the AppleFSCompressionTypeZlib instance doesn't contain the symbol _lzbitmap_decode, despite having the same code)._lzbitmap_decode uses. I'm guessing that the YMM save/restore is either a macro or an inlined library function. At the beginning of _lzbitmap_decode, all 16 YMM registers are saved on the stack, then in no fewer than six separate locations, all 16 YMM registers are restored, either from [R15] or [RAX]. What initially looked to me like manipulation of the values on the stack turned out not to involve the YMM storage area, and both R15 and RAX both get loaded with the address of the YMM storage area prior to restoring the YMM registers, so all of the instructions involving the YMM registers are purely for save/restore, and really only for the XMM (low 128 bit) portion of the registers, since that's all the code uses.// Original [RAX] restore code (AVX) (115 bytes):
c5fd6f00 vmovdqa (%rax), %ymm0
c5fd6f4820 vmovdqa 0x20(%rax), %ymm1
c5fd6f5040 vmovdqa 0x40(%rax), %ymm2
c5fd6f5860 vmovdqa 0x60(%rax), %ymm3
c5fd6fa080000000 vmovdqa 0x80(%rax), %ymm4
c5fd6fa8a0000000 vmovdqa 0xa0(%rax), %ymm5
c5fd6fb0c0000000 vmovdqa 0xc0(%rax), %ymm6
c5fd6fb8e0000000 vmovdqa 0xe0(%rax), %ymm7
c57d6f8000010000 vmovdqa 0x100(%rax), %ymm8
c57d6f8820010000 vmovdqa 0x120(%rax), %ymm9
c57d6f9040010000 vmovdqa 0x140(%rax), %ymm10
c57d6f9860010000 vmovdqa 0x160(%rax), %ymm11
c57d6fa080010000 vmovdqa 0x180(%rax), %ymm12
c57d6fa8a0010000 vmovdqa 0x1a0(%rax), %ymm13
c57d6fb0c0010000 vmovdqa 0x1c0(%rax), %ymm14
c57d6fb8e0010000 vmovdqa 0x1e0(%rax), %ymm15// Direct replacement (123 bytes):
660f6f00 movdqa (%rax), %xmm0
660f6f4820 movdqa 0x20(%rax), %xmm1
660f6f5040 movdqa 0x40(%rax), %xmm2
660f6f5860 movdqa 0x60(%rax), %xmm3
// Starting at offset 0x80, switches to 32-bit offsets
660f6fa080000000 movdqa 0x80(%rax), %xmm4
660f6fa8a0000000 movdqa 0xa0(%rax), %xmm5
660f6fb0c0000000 movdqa 0xc0(%rax), %xmm6
660f6fb8e0000000 movdqa 0xe0(%rax), %xmm7
// Starting with XMM8, an additional prefix byte is required
66440f6f8000010000 movdqa 0x100(%rax), %xmm8
66440f6f8820010000 movdqa 0x120(%rax), %xmm9
66440f6f9040010000 movdqa 0x140(%rax), %xmm10
66440f6f9860010000 movdqa 0x160(%rax), %xmm11
66440f6fa080010000 movdqa 0x180(%rax), %xmm12
66440f6fa8a0010000 movdqa 0x1a0(%rax), %xmm13
66440f6fb0c0010000 movdqa 0x1c0(%rax), %xmm14
66440f6fb8e0010000 movdqa 0x1e0(%rax), %xmm15// Condensed replacement (111 bytes):
660f6f00 movdqa (%rax), %xmm0
660f6f4810 movdqa 0x10(%rax), %xmm1
660f6f5020 movdqa 0x20(%rax), %xmm2
660f6f5830 movdqa 0x30(%rax), %xmm3
// XMM4-7 still using 8-bit offsets
660f6f6040 movdqa 0x40(%rax), %xmm4
660f6f6850 movdqa 0x50(%rax), %xmm5
660f6f7060 movdqa 0x60(%rax), %xmm6
660f6f7870 movdqa 0x70(%rax), %xmm7
// Starting with offset 0x80/XMM8, 32-bit offset + extra prefix byte
66440f6f8080000000 movdqa 0x80(%rax), %xmm8
66440f6f8890000000 movdqa 0x90(%rax), %xmm9
66440f6f90a0000000 movdqa 0xa0(%rax), %xmm10
66440f6f98b0000000 movdqa 0xb0(%rax), %xmm11
66440f6fa0c0000000 movdqa 0xc0(%rax), %xmm12
66440f6fa8d0000000 movdqa 0xd0(%rax), %xmm13
66440f6fb0e0000000 movdqa 0xe0(%rax), %xmm14
66440f6fb8f0000000 movdqa 0xf0(%rax), %xmm15fxsave64 and fxrstor64, since we have a 512-byte area on the stack to work with. However, that would involve more analysis, since fxsave64/fxrstor64 are considered floating-point instructions, which might cause complications.)movl $9,%eax clears the upper 32 bits of %RAX). However, when using non-AVX instructions, the upper bits of the YMM/ZMM registers are left undisturbed. Thus, we can safely save/restore only the XMM registers without worrying about the YMM/ZMM register bits.
Ok, I always intended on implementing your fix, just was under the impression it was still "alpha" and was trying to decide if adding it was more or less risky than not at this point as I was not experiencing the issue.