Live data from Hacker News

Reverse Engineering the M1 [pdf]

i.blackhat.com

11–20 of 58 posts

Re: Reverse Engineering the M1 [pdf]

#12
post #5
post #2

> M1 Linux does not have a cool logo or name Wonder if this is a subtle jab at Asahi Linux. Hopefully not, as I was thoroughly unamused by Corellium’s previous antics regarding Asahi Linux. It would be a lot nicer to see at least polite relations in the future, if not collaboration…

Isn't the feeling mutual? I was under the impression that Asahi didn't really want Corellium's contributions because they considered Corellium's looks at proprietary Apple code to be an existential threat to the project's need for clean room RE.

Well, they objectively were.

Re: Reverse Engineering the M1 [pdf]

#13
post #9
post #5

Earlier quoted context omitted.

Isn't the feeling mutual? I was under the impression that Asahi didn't really want Corellium's contributions because they considered Corellium's looks at proprietary Apple code to be an existential threat to the project's need for clean room RE.

In any case, it never had to turn petty, even if they really did feel like RE knowledge from Sandcastle was being used. Even if code wasn’t shared, knowledge could have been. I came out with the feeling that they had bigger concerns about optics above all, and they couldn’t use the same approaches that might’ve worked when they were the David and not the Goliath. I don’t want to be the asshole dredging up drama needl…

>Even if code wasn’t shared, knowledge could have been.

Legally it would be still an issue to share "knowledge" with someone who has seen the code.

Re: Reverse Engineering the M1 [pdf]

#14
post #13
post #9

Earlier quoted context omitted.

In any case, it never had to turn petty, even if they really did feel like RE knowledge from Sandcastle was being used. Even if code wasn’t shared, knowledge could have been. I came out with the feeling that they had bigger concerns about optics above all, and they couldn’t use the same approaches that might’ve worked when they were the David and not the Goliath. I don’t want to be the asshole dredging up drama needl…

> Even if code wasn’t shared, knowledge could have been. Legally it would be still an issue to share "knowledge" with someone who has seen the code.

Isn’t that false? I thought the fact that you could is basically the principle behind Chinese wall reverse engineering.

Re: Reverse Engineering the M1 [pdf]

#16
post #15

> A14/M1 use a non-standard NVMe queue format >USB4... but Apple made it their own, as usual I am wondering about these two points. Why ?

Think Different™

Apple has a really long history of doing stuff like that.

https://news.ycombinator.com/item?id=12924051

Re: Reverse Engineering the M1 [pdf]

#17
post #15

> A14/M1 use a non-standard NVMe queue format >USB4... but Apple made it their own, as usual I am wondering about these two points. Why ?

There's probably an interesting groupthink/psychology to Apple, but I think in this case the proprietary-ness of parts of M1 is them focusing on getting it out of the door: Apple have a lot of experience making ARM mobile chips but this was their first desktop part.

I say this based on nothing but gossip, of course.

Re: Reverse Engineering the M1 [pdf]

#18
Of course most of the platform weirdness is down to "we're vertically integrated and our business goal is the end product and getting that product done fast" but some of the design decisions are kinda baffling even when taking that into account. Like what exactly did they gain by making a weird non-PCIe NVMe situation? Is it really any easier/faster to make the kernel handle that crap than to put the drive on a virtual PCIe bus in hardware+firmware? Are they.. (oh no) trying to improve boot speed by not having to discover the drive on PCIe?!

Re: Reverse Engineering the M1 [pdf]

#19
post #15

> A14/M1 use a non-standard NVMe queue format >USB4... but Apple made it their own, as usual I am wondering about these two points. Why ?

Think Different™ Apple has a really long history of doing stuff like that. https://news.ycombinator.com/item?id=12924051

I remember when Microsoft were the archetypal "not invented here"-ers.

Re: Reverse Engineering the M1 [pdf]

#20
post #15

> A14/M1 use a non-standard NVMe queue format >USB4... but Apple made it their own, as usual I am wondering about these two points. Why ?

If you're going to have your own platform where you control all the parts and none of them are replaceable, why would you religiously stick to the standards when you don't need to? Maybe they saved a slight amount of power consumption by not supporting 64K queues, like the nvme standard supports. A standard will try to be all things to all people, but it will never be the best thing for any given application. There is always room to specialize.
Post reply on HN