Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
1–10 of 21 posts
Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
#2I wonder if they do indeed compute a checksum of the binary to come up with a aot-translation cache key. Must be quite ineffficient.
Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
#3I wonder if they do indeed compute a checksum of the binary to come up with a aot-translation cache key. Must be quite ineffficient.
Not if your SSD delivers data at more than 2500MB/sec, as the one in the MacBook Air with M1 does. SHA256 calculation can probably be performed at that speed as well, thanks to dedicated silicon, so even a large 250MB binary (haven't seen those in any other use case than browsers) would be hashed in a tenth of a second. Not noticeable at all, if it's just once, at startup.
Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
#4I wonder if they do indeed compute a checksum of the binary to come up with a aot-translation cache key. Must be quite ineffficient.
Not if your SSD delivers data at more than 2500MB/sec, as the one in the MacBook Air with M1 does. SHA256 calculation can probably be performed at that speed as well, thanks to dedicated silicon, so even a large 250MB binary (haven't seen those in any other use case than browsers) would be hashed in a tenth of a second. Not noticeable at all, if it's just once, at startup.
This also sounds like something that could be cached if the file doesn’t change.
Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
#5Earlier quoted context omitted.
Not if your SSD delivers data at more than 2500MB/sec, as the one in the MacBook Air with M1 does. SHA256 calculation can probably be performed at that speed as well, thanks to dedicated silicon, so even a large 250MB binary (haven't seen those in any other use case than browsers) would be hashed in a tenth of a second. Not noticeable at all, if it's just once, at startup.
This also sounds like something that could be cached if the file doesn’t change.
I think there is no good way of doing that. Each time the user tries to run a x86_64 binary you’d have to actually checksum, or otherwise check the content of, the x86_64 binary to know if you have a translated version of it already.
inode meta data such as timestamps are insufficient I think. They can be tampered with.
Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
#6I wonder if they do indeed compute a checksum of the binary to come up with a aot-translation cache key. Must be quite ineffficient.
[deleted]
Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
#7This isn't something I would be even remotely capable of doing myself and I probably don't understand the vast majority of what they are talking about but I absolutely love that this exists and there are people who enjoy digging into and doing a nice write up about it.
Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
#8Earlier quoted context omitted.
This also sounds like something that could be cached if the file doesn’t change.
I think there is no good way of doing that. Each time the user tries to run a x86_64 binary you’d have to actually checksum, or otherwise check the content of, the x86_64 binary to know if you have a translated version of it already. inode meta data such as timestamps are insufficient I think. They can be tampered with.
> inode meta data such as timestamps are insufficient I think. They can be tampered with.
In macOS, there is a security-policy layer of some kind on top of xattrs, separate from the security-policy of the file itself. `com.apple.rootless` is an example of an xattr protected by this mechanism: users (even root) can't apply or remove `com.apple.rootless` from files on a filesystem mounted as the rootfs.
With this mechanism, it'd likely be possible to give executable binaries an xattr containing the checksum, generated by Gatekeeper+Rosetta, that the user couldn't modify, while still being able to otherwise modify/delete the file. (And, presumably, modifying the file would automatically invalidate/remove the checksum xattr.)
Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
#9This isn't something I would be even remotely capable of doing myself and I probably don't understand the vast majority of what they are talking about but I absolutely love that this exists and there are people who enjoy digging into and doing a nice write up about it.
You can always learn! You're just a few books away from the knowledge.
Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime
#10This isn't something I would be even remotely capable of doing myself and I probably don't understand the vast majority of what they are talking about but I absolutely love that this exists and there are people who enjoy digging into and doing a nice write up about it.
You can always learn! You're just a few books away from the knowledge.
Which books?