svenpeter

I work at a unionized company in Germany and didn’t have to join the union or pay any dues to start working.

Technically employees who aren’t part of the union aren’t entitled to the benefits they negotiated. In reality everyone gets the same benefits anyway because otherwise the employer would create a huge incentive for everyone to join the union which would make strikes hurt even more.

IIRC we know about their internal Linux port because of some comment left in the open source XNU release.

That merge only has fixed because of how the development model works: there’s a merge window where new features are merged and which then becomes -rc1. After that only fixes are allowed until the final release of that version and then the merge window opens again.

The list was at least updated after iOS:

I've found wiibrew.org and hackmii.com in there which are both Wii homebrew sites that became popular around 2008/2009 and probably declined in popularity starting in ~2012/2013.

Then there's also wiiu-developers.nintendo.com and wiiudaily.com which probably didn't exist before late 2012 or early 2013 when the WiiU was released.

Will Deacon replied on Twitter how at least Linux handles this correctly [1][2] and I assume that the same is true for XNU and Windows as well.

[1] https://twitter.com/WillDeacon/status/1506375874161086471

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

I don't think ARMv8 requires EL3 but even if it did there is no EL3 on the M1.

Booting Windows natively would require Microsoft's support since some rather invasive changes to the kernel would be required (FIQ support, DART instead of SMMU) on top of implementing drivers for everything.

It’s been a while since my last physics lectures so this might be wrong, but the way i understand it:

We don’t have a good model of quantum gravity yet but our best guess is that the force carrier of gravity might be a particle called graviton. This hypothetical particle has no mass and therefore the length scale of gravity would be infinite. This matches the Newtonian and the general relativity model of gravity.

This is different from the source of gravity which would be the (gravitational) mass of an object (or more accurately the components of the stress energy tensor which describe the density and flux of energy but that’s also the point where I have to start with the hand waving because my knowledge becomes very fuzzy there)

It’s also true for the electromagnetic interaction: the force carrier here is the photon which is also massless and the length scale is also infinite here.

Yup, I'm pretty sure many software companies have done similar things. It's a bit easier on video game consoles where your software runs on the very same hardware everywhere and you can pull off more subtle tricks. There were a few commercial games that also used a similar approach [1].

[1] https://dolphin-emu.org/blog/2017/02/01/dolphin-progress-rep...

no worries, this stuff happened over a decade ago. I can sometimes barely remember the details :)

> Is it weird that you sound proud about this? Is there something noble about doing work that makes lives harder for hobbyists trying to preserve video games for the future, and has nearly zero impact on the actual sales of the game at release?

What makes you think we did it for any of those reasons? And how does us abusing hardware bugs make video game preservation any harder?

This was not for a commercial game, this was for an entry point to load your own software on a locked down video game console.

And back then people were selling our (free!) software and we added those protections to make sure we could show a "you have been scammed if you paid for this" screen that couldn't be removed. Unfortunately that also meant breaking our loader from running in emulators, but that didn't matter at all: Those could just directly launch actual .elf files anyway and didn't need the detour through the homebrew channel.

The code (minus those protections) for the Homebrew Channel is also available as open source these days.

To be fair, we deliberately used very obscure hardware "features" which we knew were not implemented by any emulators and probably not used by any games to build these protections :-)

I'd have to dig up the old code but I'm fairly sure some of them rely on an operating system (Nintendo IOS, unrelated to both Cisco's IOS and Apple's iOS) running on the co-processor (nicknamed "Starlet"). Dolphin doesn't emulate that part at all because IOS exposes a high-level interface that can just be emulated instead. Works amazingly well for games, but will probably trip our protections.

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

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.

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.

Usually, once you can run code in kernel mode it’s just a matter of bringing the hardware back to a sane state.

Unfortunately, “just” running code in kernel mode is incredibly hard on the iPad. There’s e.g. a hardware mitigation that turns a memory region to read-only and also only allows kernel code to run from this region. This mitigation is locked down and cannot be disabled once XNU is running on the iPad (http://siguza.github.io/KTRR/).

On top of that page tables are also protected by a “kernel within the kernel” (https://blog.svenpeter.dev/posts/m1_sprr_gxf)

Getting past all that is going to be very hard if not impossible.

which is not impossible but very unlikely.

That missing patch is the iommu driver which is currently under review and will hopefully make its way to mainline soon.

Once that one is merged there's already another series to enable PCIe (which needs the iommu driver) which gives us more USB ports, ethernet and with another small patch WiFi. There's also a WIP series for NVMe.

What's missing are then a few smaller things (i2c, spi, keyboard on the macbooks etc.).

And then there are a few bigger tasks left, e.g. thunderbolt support, usb super speed support, support for the secure enclave, and ofc the largest one being the display controller and the GPU.

And once that's all done there's the long tail of making this all work nicely (e.g. power management, making the installation as easy as possible, etc.)

On the computers (i.e. mac mini, macbook, iMac) Apple ships an unlocked bootloader and we can just install our own bare metal code very early on using their official tools.

On the iPad Pro that bootloader is locked down and running Linux on there is unfortunately very unlikely to ever be possible.

Not sure why you're downvoted because I think you ask a legitimate question.

To me, it's a combination of various things:

I've tried to outline the process I used so that other people can learn how to approach challenges like this. I learned how to develop software and how to reverse engineer by reading posts like this and watching talks from e.g. CCC or DEFCON. Hopefully I can give something back this way.

This might also be valuable to other people who want to virtualize macOS or iOS or those who do security research and run into these features while reading XNU code.

And then ofc I can finally flex in front of my friends with this because I was the first to pull of a new skate trick ;)

fwiw, you can disable almost all of Apple's enhanced security features easily on macOS systems.

Their whole design is incredibly neat and well done! If you like these features (or just don't care) the default install does make attacker's lives harder.

But if you disagree with these features or just don't like them you can just boot into recovery mode, authenticate with your password and disable almost everything for macOS.

And if you just like the hardware you can do the same and install a custom kernel like Linux or *BSD and do whatever you want.

You can even have triple boot into one macOS with full security enabled, another macOS install with everything disable and a third "macOS" which actually is Linux.

They spend a lot of effort and engineering time to make all this possible.

> it is, after all, a popular hobby of children who have nothing but time on their hands and access to the Internet. You certainly don’t need to buy hardware or have access to special training to get started.

yup, that's how I learned all of this!

> And, to be clear, I do think the current situation of closed systems is not great,

Agreed!

> and I do think that we do have a lot of engineers who grew up on open systems that they could tinker on going on to design things like iPhone for their children to use.

These days there are also more open system like, say, the Raspberry Pi. Back in my day (oh god, I'm growing old!) we had to first exploit video game consoles to get something comparable :-)

We made a slightly related argument when we didn't really feel like driving the WiiU homebrew scene almost 8 years ago (stop making me feel old!) [1]

[1] https://fail0verflow.com/blog/2013/espresso/

Thanks a lot! I've been trying to improve my technical writing in the past years and I'm happy to hear feedback like this :)

This is true on the iOS platforms I'd say but it's not on the macOS ones: There you can just run your own code shortly after the SoC boots and then just leave SPRR/GXF disabled. That way you can easily have all rwx pages all you want.

you can also just map the same physical memory once as rw- and once as r-x even with SPRR enabled there.

> People aren't "gifted" with technology. Oftentimes it's because they were exposed to it and didn't have other obligations combined with a mixture of curiosity that was triggered by something.

Pretty much. I learned how to reverse engineer back when I was still in school and was bored with my Wii. I wanted to run my own code on it to e.g. watch movies on my TV. But I couldn't afford to buy another computer connected to my TV. So I just had to figure out how the Wii works and how I could run my own code on it.

The privilege I had was that my parents were well-off enough to allow me to have >8 hours of free time after school and that they bought me a computer and gave me pocket money for my Wii.

> Edited to add: the author doesn't seem to themselves be heartbroken. This level of detail suggests enthusiasm.

Absolutely not! Reverse engineering is a lot of fun to me! Especially the moment of clarity when all the unknown pieces eventually fall together and I finally get the whole picture.

hi, and thanks! I'm the author of this post and I'm a little bit conflicted where I stand in this discussion.

In general, I agree that the world would be a better place if corporations would release documentation.

But my life would be much less fun then. Reverse engineering scratches a certain itch like nothing else does! So I'm kinda happy that mysteries like this exist and gladly spend my time on something like this :-)

zarvox already linked to the talk we gave at https://media.ccc.de/v/27c3-4087-en-console_hacking_2010.

We talked about how you could compute private keys but didn't release any keys for obvious reasons.

Essentially Sony had N different sets of keys protecting different levels of their system (e.g. one keyset for the hypervisor and another one for the kernel). What we found allowed to compute the private signing key given two public signatures.

Due to some technicality this meant that you needed another bug which allowed to extract these plaintext signatures. (The best comparison today would be that we found a universal code execution bug but you still needed to find your own info leak to defeat ASLR which we either didn't share or didn't have for all keysets).

What happened then was that geohot used this flaw we found together with a simple bug that leaked two plaintext signatures to extract one of the most important keys and published that one on his website.

Sony responded by suing him and us as well - probably because they assumed that we worked together. After a few month they reached a settlement with geohot where he promised to never hack any Sony product ever again. At the same time they simply dropped the lawsuit against marcan, me and a few other friends from fail0verflow without having ever served us. Those months resulted in quite some stress for me and personal and legal issues for another friend.