Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

ffri.github.io

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

#11

Post by mhh__ »

faitswulff wrote: post #10
jml7c5 wrote: post #9

Earlier quoted context omitted.

You can always learn! You're just a few books away from the knowledge.

Which books?

I think the raw reverse engineering knowhow generally comes from reading and writing low level code and reverse engineering other people's.

Atop of that you also need understanding of computer architecture, for which I vaguely recommend Hen.&Pat. but again you get this knowledge by playing around mainly.

A bit of compiler design would help too if you want to write one of these - Engineering a compiler is a good one.

Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

#12

Post by saagarjha »

codetrotter wrote: post #5
saagarjha wrote: post #4

Earlier 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.

The kernel is aware when files are modified.

Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

#13

Post by [deleted] »

codetrotter wrote: post #5
saagarjha wrote: post #4

Earlier 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.

[deleted]

Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

#15

Post by mhh__ »

rapidlua wrote: post #2

I wonder if they do indeed compute a checksum of the binary to come up with a aot-translation cache key. Must be quite ineffficient.

Is it? Checksums are something that I use rather than understand, but the CPU is doing billions of instructions per second these days and the hash only happens once

Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

#16

Post by msie »

joshstrange wrote: post #7

This 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.

I hope those same people are looking into the M1 SSD mystery.

Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

#17

Post by anyfoo »

saagarjha wrote: post #12
codetrotter wrote: post #5

Earlier quoted context omitted.

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.

The kernel is aware when files are modified.

That's not generally applicable, e.g. not if files are on an external drive, or worse, a network filesystem (where they can change even during use).

Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

#18

Post by brokenmachine »

joshstrange wrote: post #7

This 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.

Yeah, I've been interested in learning assembly/reverse engineering/ghidra at some stage, but reading stuff like this by people who understand what a computer's doing to this level makes me despair for my own lack of knowledge.

Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

#19

Post by rapidlua »

mhh__ wrote: post #15
rapidlua wrote: post #2

I wonder if they do indeed compute a checksum of the binary to come up with a aot-translation cache key. Must be quite ineffficient.

Is it? Checksums are something that I use rather than understand, but the CPU is doing billions of instructions per second these days and the hash only happens once

Do openssl speed sha256 to get the idea how high the latency for a cache hit would be. I see a throughput of ~300MiB/sec. This can be parallelised easily but still we are burning lots of CPU cycles for nothing. Bad for battery life.

https://gist.github.com/nonylene/d08977e8952c83d20d2c5f7cbaf...

Re: Reverse-engineering Rosetta 2 Part 1: Analyzing AoT files and the runtime

#20

Post by kirugan »

msie wrote: post #16
joshstrange wrote: post #7

This 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.

I hope those same people are looking into the M1 SSD mystery.

What mystery?
Post reply on HN