Re:Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files...
by saagarjha on Thursday March 04, 2021 @06:23PM
(#26349953)
This also sounds like something that could be cached if the file doesn’t change.
[ Parent
| on HN ]
Re:Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files...
by codetrotter on Thursday March 04, 2021 @06:40PM
(#26350128)
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...
by derefr on Thursday March 04, 2021 @07:37PM
(#26350738)
> 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...
by saagarjha on Thursday March 04, 2021 @09:36PM
(#26351820)
The kernel is aware when files are modified.