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

Reverse Engineering the M1 [pdf]

i.blackhat.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Reverse Engineering the M1 [pdf]

#31

Post by [deleted] »

monocasa wrote: post #10
jchw wrote: 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…

Totally agreed, the pettiness in this case (if we're reading a one-off sentence fragment in a slide correctly) is unacceptable. I was just commenting that I don't see collaboration occurring for the well meaning base differences of opinion even once you unwrap away the pettiness.

[deleted]

Re: Reverse Engineering the M1 [pdf]

#32

Post by marcan_42 »

not2b wrote: post #21
jchw wrote: post #14

Earlier quoted context omitted.

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

Emphasis on "wall" here. People who are being careful (and when your potential opponent is as big and powerful as Apple it's best to be careful) don't let the engineers who have seen the secrets talk directly to those who are doing the clean-room reimplementation. The first group documents what they found and how they found it, lawyers check the report for anything iffy, and if the implementers need to talk to the fi…

That interpretation of "clean room" is largely a myth in the context of open source reverse engineering projects. That level of rigour only really applies when you have companies directly opposed to each other, e.g. someone making unlicensed games for a game console by reverse engineering the DRM.

Clean-rooming is not a legal requirement to avoid copyright infingement; it's a legal defense against claims of copyright infringement.

In practice, the goal when doing open source projects like this, without a legal team to consult, is to use methods and approaches that yield a result similar to strict clean-room RE and result in an end product that is not a derivative work of the original code. The tricky thing here is that you need to be able to trust that the people doing the work knows how to do this safely.

Re: Reverse Engineering the M1 [pdf]

#33

Post by SilverRed »

8note wrote: post #23
ksec wrote: 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 ?

For USB, apple makes proprietary connectors so that competing cable makers have to pay them to license it (along with other licensing terms)

This is not true of any M1 device.

Re: Reverse Engineering the M1 [pdf]

#34

Post by marcan_42 »

floatboth wrote: post #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 virtu…

Why have PCIe when you don't need it? Nothing else is on PCIe internally on mobile SoCs. It's just not a thing. That would just add silicon that you don't need.

All these "crazy" design decisions only look crazy from the point of view of x86/server hardware. From the point of view of an embedded SoC this is all reasonable and standard practice.

Re: Reverse Engineering the M1 [pdf]

#35

Post by marcan_42 »

ksec wrote: 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 ?

The non-standard NVMe queue format is because they support offloading encryption/decryption to the NVMe controller, so they had to increase the queue entry size to be able to fit an encryption key in there.

Re: Reverse Engineering the M1 [pdf]

#36

Post by marcan_42 »

xuki wrote: post #30
marcan_42 wrote: post #26

Earlier quoted context omitted.

I'm pretty sure it is. They also apparently still haven't figured out that they have a bad setting in their tunables (that macOS does not do) which disables the SError reports when I/O writes are using the wrong type. They definitely don't get "silently" ignored if you don't turn off the error reports :-) But this presentation finally answers the question of why Corellium did this. It wasn't a fun side project or a w…

> I should probably give a talk on m1n1 and the hypervisor I built for M1 reverse engineering... Please do. Pretty please.

Not in "proper talk" format, but I do have a 3h stream where I go over the hypervisor, why it was made, and how all the different parts of the code work, if you're interested.

https://youtu.be/igYgGH6PnOw

Re: Reverse Engineering the M1 [pdf]

#37

Post by ribit »

floatboth wrote: post #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 virtu…

Well, their SSDs are not PCI-e devices, they are directly connected to the SoC. I think that their use of NVMe is just a compatibility stop gap, they will probably move to a custom direct-access interface in the near future.

Re: Reverse Engineering the M1 [pdf]

#38

Post by svenpeter »

marcan_42 wrote: post #35
ksec wrote: 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 ?

The non-standard NVMe queue format is because they support offloading encryption/decryption to the NVMe controller, so they had to increase the queue entry size to be able to fit an encryption key in there.

The "queue" format itself is incredibly similar to the normal NVMe queue.

The normal queue is (more-or-less) a ringbuffer with N slots in memory and a head/tail pointer. You append the command to the next slot and increase the tail by writing to a doorbell. Once the controller is done it increases the head the same way.

Apple's "queue" instead is just a memory region without those head/tail pointers. Command submission now works by again putting the request into a free slot followed by just writing the ID of that slot to a MMIO register. Once a command is done the CPU again gets an interrupt and can just take the command out of the buffer again.

This probably makes the driver a little bit easier to implement.

On top of that a similar structure (which identifies the DMA buffers that need to be allowed) also needs to be put into their NVMe-IOMMU with a reference to the command buffer entry. The slightly weird thing about the encryption is that you put the key/iv into this buffer instead of the normal queue. My best guess is that this IOMMU design pushed them to also simplify the command queue to make the matching easier.

Hiding the encryption part inside the IOMMU also makes sense for them because the whole IOMMU management is hidden inside a highly protected area of their kernel with more privileges while the NVMe driver itself is just a regular kernel module which possibly doesn't have access to keys.

Re: Reverse Engineering the M1 [pdf]

#39

Post by svenpeter »

floatboth wrote: post #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 virtu…

NVMe requires a co-processor (which Apple calls "ANS") to be up and running before it works. This co-processor firmware seems to have a lot of code and strings dealing with PCIe. Now I haven't looked at the firmware in detail but I'm willing to bet that the actual drives are on a PCIe bus (or at least used to be on a PCIe bus on previous hardware).

It's just that this bus is not exposed to the main CPU but only to this co-processor instead. The co-processor then seems to emulate (or maybe it's just a passthrough) a relatively standard NVMe MMIO space.

Re: Reverse Engineering the M1 [pdf]

#40

Post by [deleted] »

floatboth wrote: post #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 virtu…

[deleted]
Post reply on HN