Correctly handle dyld caches on macOS 13 and above

[mstange]

This allows successful parsing of dyld caches on macOS 13 and above on Intel Macs.

The main dyld cache file on macOS contains an array of subcache info structs, each of which specifies the UUID (and some other information) of each subcache.
DyldCache::parse checks that the subcache UUIDs match these expected UUIDs.

In macOS 13, the format of the subcache info struct changed: the struct gained an additional field after the UUID field. This means that as soon as you had more than one subcache, our UUID check would fail, because the second subcache UUID would be read from the wrong offset.

I didn't notice this on my Apple Silicon Mac, because the arm64e dyld cache only has one subcache:
dyld_shared_cache_arm64e.01.
But on Intel Macs, there are currently four subcaches: dyld_shared_cache_x86_64.01, .02, .03, and .04.

In practice this means that my software hasn't been able to symbolicate macOS system libraries on Intel Macs since the release of macOS 13.

This commit adds the new struct definition and makes the UUID check work correctly.

This is a breaking change to the public API. I added a DyldSubCacheSlice enum, but I'm not particularly fond of it.
I'm also not a big fan of the new allocation for the Vec of UUIDs, but it seemed better than the alternatives I tried, which all had a bunch of code duplication.

dyld source code:

• dyld_cache_header struct definition
• dyld_subcache_entry_v1 and dyld_subcache_entry struct definitions
• A check for whether subcache information is present
• A check for whether V2 information is present

I've changed MIN_HEADER_SIZE_SUBCACHES_V1 to be 0x1c8 instead of 0x1c4 because we use a >= check on it. dyld uses a > check with the offset of the subCacheArrayCount field (called images_across_all_subcaches_count in our definition), so what dyld is doing is a equivalent to a > 0x1c4 check. Rather than changing our check to be a > check, I've kept it as a >= because that fits better with the MIN_HEADER_SIZE name, and instead increased the offset to point to the end of the field instead of the beginning.

I didn't touch our definition of DyldCacheHeader. It's quite incomplete because the dyld source with the new header fields hadn't been released yet at the time I wrote the object code. Now that it's out, we could flesh out our type definition a bit, but I don't have an urgent need for that at the moment.

[philipc]

Are you aware of any easy way to test this without owning Apple hardware (both Apple silicon and Intel)? The best I have currently is using whatever machines CI provides.

[philipc]

Currently the examples (objdump and dyldcachedump) only load subcaches with either an integer suffix or ".symbols" suffix, and DyldCache::parse relies on the provided subcache_data matching the subcaches. Is this going to work now that DyldSubCacheEntryV2::file_suffix can be anything?

[mstange]

Are you aware of any easy way to test this without owning Apple hardware (both Apple silicon and Intel)? The best I have currently is using whatever machines CI provides.

The two ways I can think of involve quite a bit of effort:

• We could try to pull the caches from the Apple update servers, similar to what the macOS symbol scraper in mozilla-central was attempting to do. That scraper is not currently working for macOS 11+ because it needs more work. Last I checked, running these scripts also requires large amounts of disk space.
• We could try to compile dyld ourselves and create our own caches for testing, specifically we could probably use the dyld_shared_cache_builder binary. In my past attempts to build dyld I had to hack around the absence of certain header files and #defines, and additionally we'll probably want to change these subcache size constants so that our test cache isn't enormous.

Currently the examples (objdump and dyldcachedump) only load subcaches with either an integer suffix or ".symbols" suffix, and DyldCache::parse relies on the provided subcache_data matching the subcaches. Is this going to work now that DyldSubCacheEntryV2::file_suffix can be anything?

Oh, I had forgotten about these examples. You're right that they currently won't work - on macOS 13, the suffixes now have a leading zero.
And we may want a better API in this crate, so that users can list the suffixes before they read the subcache data. In samply, I just read all available files like this: https://github.com/mstange/samply/blob/8d4770d8c3e2bbf509b405b30cc54e89d27c43b5/samply-symbols/src/macho.rs#L243-L259
But this assumes that the suffix is either .1, .01, or .symbols, which is so far the only type of suffix I've observed in the caches that ship with macOS. But the dyld source suggests that there are also "development" caches with other suffixes, and anyway it would be more reliable to use the suffixes written down in the main cache.

With the current state of this PR, users of object would have to call macho::DyldCacheHeader::parse themselves for the main cache in order to list the subcaches, and then call DyldCache::parse once they have the subcache data, which parses the main cache header again.

[mstange]

Oh, I had forgotten about these examples. You're right that they currently won't work - on macOS 13, the suffixes now have a leading zero.

The dyldcachedump example was already taking the leading zero into account, so it was working, modulo the UUID verification issue. The objdump example was not using a leading zero so it failed to load the subcaches and said "Failed to parse file: Unsupported file format".
I'm going to add a commit which changes both to take the suffix from the header.

[philipc]

LGTM. I assume you want a release with this soon?

[mstange]

LGTM. I assume you want a release with this soon?

Thank you! A release would be appreciated.