Comments URL: https://news.ycombinator.com/item?id=44823451

Points: 12

# Comments: 1

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.

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.

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

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

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.

Comments URL: https://news.ycombinator.com/item?id=29564384

Points: 367

# Comments: 211

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.

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

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.

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.

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

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.

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 iPad Pro that bootloader is locked down and running Linux on there is unfortunately very unlikely to ever be possible.