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

51–58 of 58 posts

Re: Reverse Engineering the M1 [pdf]

#51

Post by marcan_42 »

ribit wrote: post #37
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.

They're using NVMe with customizations because NVMe is a good standard. There's no reason to reinvent it from scratch when it works; they can just make the non-standard changes they feel like making, as they have already done.

There's no fundamental reason why NVMe has to be tied to PCIe; it just happens to be that way on existing devices.

Re: Reverse Engineering the M1 [pdf]

#52

Post by rowanG077 »

marcan_42 wrote: post #47
rowanG077 wrote: post #7

Earlier quoted context omitted.

I believe this is false. The Corellium guys are (much?) further along technically. But they don't care to put their code in a format that upstream will ever accept. I believe this was the main reason collaboration went nowhere. Corelliums forked kernel will always be little more then a marketing toy because of this.

FWIW, they had a ~year of head start working on their A14 kernel, but they also haven't done any graphics work and our userspace stack now passes >90% of the GLESv2 tests... so I'm not sure it's fair to say their demo kernel (which they haven't touched since February) is further along technically any more. We're focusing on different things, and now that the DART code is in good shape (which makes PCI and USB work) a…

I assumed they had a working graphics stack when I said they are further along :p. But yeah I follow the asahi channels on IRC and am a github sponsor myself!

So I'm definitely not knocking on you guys effort or anything. I'm very grateful I will soon have the opportunity to buy a thin & light laptop that doesn't throttle itself into the ground if you so much as even think about using the GPU.

Re: Reverse Engineering the M1 [pdf]

#53

Post by svenpeter »

marcan_42 wrote: post #50
svenpeter wrote: post #39

Earlier quoted context omitted.

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 th…

Yes, the raw NAND storage modules are connected over PCIe on all M1 machines, to dedicated root ports that are behind ANS. As far as I can tell ANS implements (parts of?) the FTL and data striping and other high-level features, and effectively RAIDs together the underlying storage modules into a single unified NVMe interface. So in this sense, the PCIe here is just an implementation detail, the physical/logical inter…

Ah, that makes a lot of sense. Then this unified MMIO NVMe is "just" emulated inside ANS.

Re: Reverse Engineering the M1 [pdf]

#54

Post by asddubs »

marcan_42 wrote: post #49
floatboth wrote: post #44

Earlier quoted context omitted.

Well, yeah – embedded standard practice is not caring about standards and expecting the kernel to accommodate you . Makes sense for Apple with their vertical integration, but even the less integrated things do that, see the entire concept of a "BSP". But that is what sucks. That's why embedded is creating all these piles of e-waste doomed to only run crappy outdated vendor kernels unless someone invests huge effort i…

Embedded has the DeviceTree standard to serve the same purpose as PCIe enumeration. This is even supported inside UEFI (which is how we will boot standard distros, once our kernel patches trickle upstream). There's no reason why not using PCIe means "creating all these piles of e-waste doomed to only run crappy outdated vendor kernels". What does that isn't whatever choice of device enumeration you use, it's vendors…

how exactly does one standardize DeviceTree bindings?

Re: Reverse Engineering the M1 [pdf]

#55

Post by marcan_42 »

asddubs wrote: post #54
marcan_42 wrote: post #49

Earlier quoted context omitted.

Embedded has the DeviceTree standard to serve the same purpose as PCIe enumeration. This is even supported inside UEFI (which is how we will boot standard distros, once our kernel patches trickle upstream). There's no reason why not using PCIe means "creating all these piles of e-waste doomed to only run crappy outdated vendor kernels". What does that isn't whatever choice of device enumeration you use, it's vendors…

how exactly does one standardize DeviceTree bindings?

The canonical repo is the Linux kernel tree, so you go through there (and the DeviceTree maintainers). This is mostly for practical reasons since they are the primary consumer, but the bindings are packaged for use by other OSes too.

Re: Reverse Engineering the M1 [pdf]

#56

Post by wtallis »

floatboth wrote: post #43
wtallis wrote: post #28

Earlier quoted context omitted.

> Like what exactly did they gain by making a weird non-PCIe NVMe situation? When Intel did exactly that, there was a clear plausible chain of decisions leading to that madness. I have no clue what may have led Apple in this direction, but the excuses probably aren't any more pathetic than trying to explain why Intel has shipped two mutually-incompatible "solutions" for preventing NVMe drives from working out of the…

VMD is weird, but at least it doesn't require big intrusive changes like decoupling your NVMe driver from PCIe. It's more like a weird special PCI-PCI bridge. Only needs a little extra driver: https://reviews.freebsd.org/D21383

VMD isn't the only method Intel has used to mess with how NVMe works. Their consumer chipsets going back at least to Kaby Lake had an even weirder "feature" that hid NVMe devices from PCIe enumeration and made them only accessible through proprietary interfaces on the chipset's SATA controller. Intel had to start using VMD on consumer platforms instead when AMD forced them to start providing more PCIe lanes from the CPU.

Re: Reverse Engineering the M1 [pdf]

#57

Post by CRConrad »

puszczyk wrote: post #6
CRConrad wrote: post #3

That's easy: Build a 1970s Italian supercar-style chassis -- heck, get some consulting help from Lamborghini, if you need -- but then, in stead of a V12 or even a V8, put one of your trusty Bavarian straight-sixes in the middle of it. What, you mean someone else is trying to usurp the venerated "M1" moniker?!? Infidels! . https://en.wikipedia.org/wiki/BMW_M1

Arguably, the comment is off-topic, but TIL about bmw m1 :)

Take that, downvoters! :-D

Myself, I'm so old I genuinely still think of that first when I see the string "M1". (Also, I hear it's a motorway in England.) So I thought it could be worth mentioning as A) a reminder that headlines could be clearer, and B) an interesting tidbit of knowledge for those who weren't familiar with what else the name could refer to.

Re: Reverse Engineering the M1 [pdf]

#58

Post by monocasa »

svenpeter wrote: post #39
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 th…

Are there any plans to replace the Apple firmware for ANS as well, or is that so locked down with signature checks that we can't expect to be able to?
Post reply on HN