Introduction to Apple Silicon(github.com)
github.com
Introduction to Apple Silicon
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon
123 comments
Discussed (a bit) here:
AsahiLinux's Introduction to Apple Silicon - https://news.ycombinator.com/item?id=30699794 - March 2022 (5 comments)
Edit: I think it makes sense for us to change the URL from https://github.com/AsahiLinux/docs/wiki/Apple-Silicon-Subsys... to this.
Lists of other pages tend not to make good HN submissions—as HN itself is already a list of pages, it's too much indirection. It's better to submit the most interesting element of the list. If there's a more interesting page than the overview one, we can change the above URL again.
AsahiLinux's Introduction to Apple Silicon - https://news.ycombinator.com/item?id=30699794 - March 2022 (5 comments)
Edit: I think it makes sense for us to change the URL from https://github.com/AsahiLinux/docs/wiki/Apple-Silicon-Subsys... to this.
Lists of other pages tend not to make good HN submissions—as HN itself is already a list of pages, it's too much indirection. It's better to submit the most interesting element of the list. If there's a more interesting page than the overview one, we can change the above URL again.
There is a huge difference between not physically locking people out of running custom software and legitimately being able to claim you support other operating systems. Requiring that a community exist that is willing to spend many years of collective time reverse engineering your products when you could have just released documentation is still a massive middle finger to everyone.
The problem with these 100% vertically integrated stacks is that every hardware release could be completely different and it'll take years to catch up with just that release. In the intervening time more hardware generations were released - It's been 18 months since the M1 release. Asahi doesn't have 3D acceleration, video encode/decode acceleration, or support for many of the things that make Apple Silicon any good (i.e. the fixed function / low power consumption hardware for the majority of user tasks). At this rate it's going to be years before it's "done" and we already have a successor generation of hardware.
I'll leave you with a quote from the Asahi docs
> Development for an undocumented platform is a treadmill of work. Every new feature requires reverse engineering the relevant hardware, writing drivers, testing those drivers, then getting them upstreamed. Even after a driver is upstreamed, maintenance and optimisation is sometimes required, for example if Apple introduce a breaking change to any firmware we are required to interface with. For developers the work is never really done
It's the same reason we don't have third-party images for most Android phones that are anything beyond tweaks of existing Android images.
The problem with these 100% vertically integrated stacks is that every hardware release could be completely different and it'll take years to catch up with just that release. In the intervening time more hardware generations were released - It's been 18 months since the M1 release. Asahi doesn't have 3D acceleration, video encode/decode acceleration, or support for many of the things that make Apple Silicon any good (i.e. the fixed function / low power consumption hardware for the majority of user tasks). At this rate it's going to be years before it's "done" and we already have a successor generation of hardware.
I'll leave you with a quote from the Asahi docs
> Development for an undocumented platform is a treadmill of work. Every new feature requires reverse engineering the relevant hardware, writing drivers, testing those drivers, then getting them upstreamed. Even after a driver is upstreamed, maintenance and optimisation is sometimes required, for example if Apple introduce a breaking change to any firmware we are required to interface with. For developers the work is never really done
It's the same reason we don't have third-party images for most Android phones that are anything beyond tweaks of existing Android images.
It's difficult to have an opinion here as I've seen both sides. While compatibility is nice, if you start kicking out reference hardware documentation you instantly open up several additional cans of worms from upstream IP licensing to crappy clone repair parts appearing on the market.
But realistically with Apple you don't know what's going to happen. They could be silent forever. They could suddenly dump a whole pack of documentation out tomorrow. An official position would be nice.
Switching it round though, 99.99% of customers are buying a toaster. I put bread in. It makes toast. I eat toast. Does it make commercial sense to support the 0.01% use case? That's their equivalent model of supporting the iPhone 5's market share for example.
But realistically with Apple you don't know what's going to happen. They could be silent forever. They could suddenly dump a whole pack of documentation out tomorrow. An official position would be nice.
Switching it round though, 99.99% of customers are buying a toaster. I put bread in. It makes toast. I eat toast. Does it make commercial sense to support the 0.01% use case? That's their equivalent model of supporting the iPhone 5's market share for example.
> But realistically with Apple you don't know what's going to happen. They could be silent forever. They could suddenly dump a whole pack of documentation out tomorrow. An official position would be nice.
Apple implementing things like they have here is about as official a position they can make without making commitments to having to respond to requests from developers as to how to do this.
Apple implementing things like they have here is about as official a position they can make without making commitments to having to respond to requests from developers as to how to do this.
It's similar with their stance to Hackintosh, but more legal.
It was a violation of their terms of service, but they didn't prosecute people that didn't try to make money with it.
It's like saying "we'll leave this tiny window open. Suit yourselves"
It was a violation of their terms of service, but they didn't prosecute people that didn't try to make money with it.
It's like saying "we'll leave this tiny window open. Suit yourselves"
> Switching it round though, 99.99% of customers are buying a toaster. I put bread in. It makes toast. I eat toast. Does it make commercial sense to support the 0.01% use case?
Fair enough. I think most toaster manufacturers will at least test what happens when you put a bagel inside, though. If said bagel causes an electrical fire or doesn't toast as well as the previous model did, it doesn't matter if ~1% of users will encounter it; it probably needs to get fixed before it ships.
I think this fully extends to Apple Silicon as well. Apple's "contributions" to Asahi mostly amount to adding a feature that pre-existed on x86 machines, and probably intended for Bootcamp/Windows rather than Linux. Hell, there's compelling evidence that Apple simply uses that functionality to flash testing firmware onto Macbooks, and the Linux compatibility is just a nice side-effect. Much like you said though, with Apple you never know. Until they release an official statement on the matter, it can only be assumed it's a coincidence.
Fair enough. I think most toaster manufacturers will at least test what happens when you put a bagel inside, though. If said bagel causes an electrical fire or doesn't toast as well as the previous model did, it doesn't matter if ~1% of users will encounter it; it probably needs to get fixed before it ships.
I think this fully extends to Apple Silicon as well. Apple's "contributions" to Asahi mostly amount to adding a feature that pre-existed on x86 machines, and probably intended for Bootcamp/Windows rather than Linux. Hell, there's compelling evidence that Apple simply uses that functionality to flash testing firmware onto Macbooks, and the Linux compatibility is just a nice side-effect. Much like you said though, with Apple you never know. Until they release an official statement on the matter, it can only be assumed it's a coincidence.
> Apple's "contributions" to Asahi mostly amount to adding a feature that pre-existed on x86 machines
Nope.
Apple tossed out the UEFI used by Intel Macs and replaced it with a system that allows you to control the security settings per partition, so you can have a single machine with full security enabled on your Mac partition while allowing for the installation of an unsigned OS on the same disk.
It's a complete replacement of the boot system that preexisted on x86 machines.
Nope.
Apple tossed out the UEFI used by Intel Macs and replaced it with a system that allows you to control the security settings per partition, so you can have a single machine with full security enabled on your Mac partition while allowing for the installation of an unsigned OS on the same disk.
It's a complete replacement of the boot system that preexisted on x86 machines.
It’s been 18 months on an entirely new platform and a small team of (BRILLIANT) people did such a good job discovering and porting to undocumented hardware that it worked on the M2 hardware essentially before it started shipping.
I don’t think Apple is trying to get in their way.
Also… developing for documented hardware is also an endless treadmill of work as it evolves/new products are released.
It just has much less uncertainty.
I 100% agree it would be awesome if Apple released full documentation. Broadcom too. Probably others.
(All IMHO)
I don’t think Apple is trying to get in their way.
Also… developing for documented hardware is also an endless treadmill of work as it evolves/new products are released.
It just has much less uncertainty.
I 100% agree it would be awesome if Apple released full documentation. Broadcom too. Probably others.
(All IMHO)
Ah, does not releasing full documentation not count as Apple "trying to get in their way"? Not trying to be snarky, genuinely trying to figure out how folks draw the line, since in my head, keeping documentation private smells like obstructionism.
Have you never been involved in the process of making internal information public? In most companies it's not just a case of whack that shit online, there's a lot of process involved in making sure it is fit for public consumption and nothing that legal, sales, product development, etc. don't want leaked is in there. This kind of overhead only grows with the size of the company and number of interested parties. You then have to justify expending that time and effort, and the ROI of making documentation public is.. not in your favor.
If it's obstructionism it's passively so. They've done nothing to actively obstruct. They've also done nothing to help. When they say they don't support it they're not kidding, they don't just mean capital-S support.
If I had to put a label on their stance, it'd be "chaotic neutral".
If I had to put a label on their stance, it'd be "chaotic neutral".
Except they have helped, just not with the documentations side: https://news.ycombinator.com/item?id=29591578
That's not helping Asahi. Apple never mentioned the reason behind the change (or even publicly acknowledged Asahi, as far as I'm aware), and non-Marcan sources have speculated that it was added to help Apple run hardware testing firmware. It's equally likely that Apple added this in as an alternate entrypoint for Bootcamp, which wouldn't work on Apple Silicon otherwise. In other words, people are applauding Apple for fixing the problem Apple created: a perfect allegory for developers in the 21st century, if you ask me.
Putting in all the effort to design a system that allows you to install an unsigned OS without it effecting the boot security of the MacOS partition is definitely helping Ashai, NetBSD and any other OS that would like to add support for the hardware going forward.
Also, designing the boot menu so that unsigned OSes can show up as valid choices or be set as the default OS.
As well as the EULA allowing the use of unsigned OSes.
Also, designing the boot menu so that unsigned OSes can show up as valid choices or be set as the default OS.
As well as the EULA allowing the use of unsigned OSes.
All of those things you listed also existed on x86 Macs, I fail to see how this represents a change in attitude towards supporting Linux users.
>All of those things you listed also existed on x86 Macs
Nope. Security settings on the Intel Macs were per machine just like other PCs.
The system of allowing per partition security settings so the user could install an unsigned OS without it effecting the security when booted into MacOS is new on Apple Silicon Macs.
As the Asahi Wiki puts it:
>From a security perspective, these machines may possibly qualify as the most secure general purpose computers available to the public which support third-party OSes, in terms of resistance to attack by non-owners.
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
Nope. Security settings on the Intel Macs were per machine just like other PCs.
The system of allowing per partition security settings so the user could install an unsigned OS without it effecting the security when booted into MacOS is new on Apple Silicon Macs.
As the Asahi Wiki puts it:
>From a security perspective, these machines may possibly qualify as the most secure general purpose computers available to the public which support third-party OSes, in terms of resistance to attack by non-owners.
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
> non-Marcan sources have speculated that it was added to help Apple run hardware testing firmware
Those sources are wrong. Apple doesn’t need to add or release anything to test their own hardware, they have an in-house Linux that hardware bringup uses.
Those sources are wrong. Apple doesn’t need to add or release anything to test their own hardware, they have an in-house Linux that hardware bringup uses.
That makes sense, fair enough, thanks!
> small team of (BRILLIANT) people
I wasn't trying to take anything away from them at all. It's astounding what they're accomplishing but the fact that it's necessary for this situation to exist at all is what I'm mainly commenting about.
I wasn't trying to take anything away from them at all. It's astounding what they're accomplishing but the fact that it's necessary for this situation to exist at all is what I'm mainly commenting about.
Speaking from experience, there is no "full documentation" to release.
> The problem with these 100% vertically integrated stacks is that every hardware release could be completely different and it'll take years to catch up with just that release. In the intervening time more hardware generations were released
>At this point, it's pretty likely that M2 will be at feature parity with M1 with <24h of actual work.
https://twitter.com/marcan42/status/1542957901651685376
>At this point, it's pretty likely that M2 will be at feature parity with M1 with <24h of actual work.
https://twitter.com/marcan42/status/1542957901651685376
[deleted]
M2 is also basically the same chip.
Which makes the scaremongering about it theoretically taking years to add support for a next generation chip sound especially silly.
Well keep in mind that even M1 2+ years since its release is not yet fully supported enough to make it a daily driver with Linux. And it is not exactly a given.
Seems like it’s reaching that point for Linus
>On a personal note, the most interesting part here is that I did the release (and am writing this) on an arm64 laptop. It's something I've been waiting for for a _loong_ time, and it's finally reality, thanks to the Asahi team. We've had arm64 hardware around running Linux for a long time, but none of it has really been usable as a development platform until now.
https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...
>On a personal note, the most interesting part here is that I did the release (and am writing this) on an arm64 laptop. It's something I've been waiting for for a _loong_ time, and it's finally reality, thanks to the Asahi team. We've had arm64 hardware around running Linux for a long time, but none of it has really been usable as a development platform until now.
https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...
> Not that I've used it for any real work, I literally have only been
doing test builds and boots and now the actual release tagging.
Linus mostly compiles kernels and merges things and maybe replies to emails using a terminal, which is very different than most non-kernel development folks' idea of daily driveable. There's the whole GPU thing for example.
As a different reminder - Linux never worked really all that well on Apple's x86 hardware in the recent past!
Also as an compare and contrast - Lenovo has a dedicated Linux team to support Linux on standard x86 hardware - https://www.phoronix.com/news/Lenovo-Linux-2022-State - so does Dell. It takes a lot more than oh we will merely make sure other OS is a policy and rest is left to you to figure out OtherOS folks.
Linus mostly compiles kernels and merges things and maybe replies to emails using a terminal, which is very different than most non-kernel development folks' idea of daily driveable. There's the whole GPU thing for example.
As a different reminder - Linux never worked really all that well on Apple's x86 hardware in the recent past!
Also as an compare and contrast - Lenovo has a dedicated Linux team to support Linux on standard x86 hardware - https://www.phoronix.com/news/Lenovo-Linux-2022-State - so does Dell. It takes a lot more than oh we will merely make sure other OS is a policy and rest is left to you to figure out OtherOS folks.
The parts are clearly cross-compatible and we’re again faced with what seems like an attempt to block repairs and replacements through software barriers. - https://www.ifixit.com/News/62684/were-pretty-sure-we-just-t...
That's a pretty misleading quote out of context (and to be honest, it's not great even with context - there's no real grounds for iFixit to make that assertion) - Apple made changes at the hardware & software level to how the touchpad & keyboard work - offloading more functionality to the main SoC, changing the comms protocol, etc.
There's no evidence at all that it is an attempt to block repairs with older hardware.
edit: if you think about it, it's even more awkward for Apple - now they have to have two sets of parts inventory for repairs, etc. It doesn't really make sense to do that unless you have a technical justification.
There's no evidence at all that it is an attempt to block repairs with older hardware.
edit: if you think about it, it's even more awkward for Apple - now they have to have two sets of parts inventory for repairs, etc. It doesn't really make sense to do that unless you have a technical justification.
Does Apple have less reason to lock things down now? Being fully vertically integrated, with possibly the best mobile hardware in town, do they care that people will buy their hardware just to run Linux?
Help is good. But getting out of the way sounds like a good consolation prize.
Help is good. But getting out of the way sounds like a good consolation prize.
Apple has never locked down a Mac.
The EULA on the Apple Silicon Macs allows you to run another OS.
Apple put in a large amount of work to design a system that applies security settings per partition instead of per machine, so that installing an unsigned custom OS doesn't require you to turn off "Secure Boot" for the whole machine.
The EULA on the Apple Silicon Macs allows you to run another OS.
Apple put in a large amount of work to design a system that applies security settings per partition instead of per machine, so that installing an unsigned custom OS doesn't require you to turn off "Secure Boot" for the whole machine.
Wait what? Did Intel macs have EULAs that go into what OSes you're allowed to install on the hardware you "own"? It blows my mind that we'd need Apple's permission, unless you're just licensing/renting your mac
When I used to have a personal macbook that I got to keep after an old internship, I even was able to find instructions online that helped me split the SSD between Linux and MacOS, with filevault still working on the MacOS partition and full disk encryption through LUKS like normal on Linux. It did require temporarily turning off filevault and SIP while doing the partitioning (and when setting the linux partition to boot by default, although that's not required by any means), but once the setup is done, it works fine after turning it back on.
> Requiring that a community exist that is willing to spend many years of collective time reverse engineering your products when you could have just released documentation is still a massive middle finger to everyone.
If you were handling this situation for Apple, how would you handle customer support for non-apple OSes?
If you were handling this situation for Apple, how would you handle customer support for non-apple OSes?
I mean I wouldn't, but documentation would be appreciated. I feel like this is a common error in reasoning (not accusing you, honestly not accusing Apple, mostly accusing the people who would move the goalposts if Apple really did release documentation) where you identify one action as clearly good, and another action as possibly bad, and then not do the former for fear that you'll then choose to do the latter.
It's not quite slippery slope, because at least under slippery slope it's other people who are the concern. Apple could just choose to do the easy stuff and not the hard stuff! They could release documentation with no promise of support! You see the same argument with open sourcing things; "Oh well then I'd have to support it". Just literally choose to let people see the code and also choose not to give them support. Who exactly is gonna twist your arm?
It's not quite slippery slope, because at least under slippery slope it's other people who are the concern. Apple could just choose to do the easy stuff and not the hard stuff! They could release documentation with no promise of support! You see the same argument with open sourcing things; "Oh well then I'd have to support it". Just literally choose to let people see the code and also choose not to give them support. Who exactly is gonna twist your arm?
M2 is already out and marcan got it up and running in, like, a few hours. Apple actually has a fair bit of engineering discipline and doesn't shuffle registers around on a whim. This isn't exactly Intel levels of "lol let me just run MS-DOS on my brand-new gaming rig" but it's way better than most ARM vendors.
If Qualcomm or Nvidia had half the compatibility discipline Apple had, third-party images for Android hardware would absolutely be a thing.
If Qualcomm or Nvidia had half the compatibility discipline Apple had, third-party images for Android hardware would absolutely be a thing.
Agree with the sentiment of siblings. Apple writing public documentation would have a cost (server maintenance, full time technical writers, support for devs etc), and how would they justify it? Their mantra has always been a single unit formed by their hardware AND software. They are nice enough to allow you to play with the hardware and keep the security features, I don't think you should expect much more.
Apple has had lacking documentation for more than a decade now. They haven’t invested enough in that area, and I presume they are incapable of cleaning up their internal documents for external use.
I'm a lot less worried about Apple closing off alternate operating systems than I am about not being able to replace the SSD when it inevitably dies. I'd dearly love a Mac Studio, but not if it's guaranteed to become an expensive paperweight for lack of serviceability. I routinely keep computers 10+ years, and unless Apple's SSD can last that long without babying it to a ridiculous degree, it's a non-starter.
As someone who grew up with an Apple II+, this "no user serviceable parts inside" mentality has infuriated me about Apple since 1984, so this is nothing new. I've long wanted to love Apple products, but that footgun just has to come out.
But I'll give Apple a great deal of credit that they have (even if unofficially) helped rather than hindered the Asahi project. Make a Mac that uses off-the-shelf SSDs at the very least (RAM is a second rant), and I'd be in "shut up and take my money" mode.
As someone who grew up with an Apple II+, this "no user serviceable parts inside" mentality has infuriated me about Apple since 1984, so this is nothing new. I've long wanted to love Apple products, but that footgun just has to come out.
But I'll give Apple a great deal of credit that they have (even if unofficially) helped rather than hindered the Asahi project. Make a Mac that uses off-the-shelf SSDs at the very least (RAM is a second rant), and I'd be in "shut up and take my money" mode.
The Studio actually has removable NAND cards though, like the Mac Pro.
The flash controller for the Studio is integrated onto the SOC instead of being a separate chip on the NAND card. So that's different.
That's good to hear, at least, and it made me look deeper. It's not your standard SSD, but it is replaceable, with caveats. In particular, don't expect your SSD to boot in someone else's Mac unless you wipe it.
Still, this a much more palatable proposition than soldered-in storage. Just be sure you get the RAM you need, because there's no upgrading it.
https://arstechnica.com/gadgets/2022/03/explaining-the-mac-s...
Still, this a much more palatable proposition than soldered-in storage. Just be sure you get the RAM you need, because there's no upgrading it.
https://arstechnica.com/gadgets/2022/03/explaining-the-mac-s...
Some kind of workaround for this might be an external bootable SSD, with 40 Gbp/s theoretical bandwidth there should be no limitation from that side at least. Just create a bootable SSD before this machine's SSD dies
Arm Macs require the internal hard drive to boot. It loads its booting sequence from the drive, even if it is set to default to an external drive for its OS.
> Definitely worth referencing next time someone on HN or elsewhere claims Apple's trying to lock down their computers to running macOS only.
The Asahai Linux lead Has addressed this directly today.
>Okay, it's been over a year, and it's time to end the nonsense speculation.
I have heard from several Apple employees that:
1. The boot method we use is for 3rd-party OSes, and Apple only use it to test that it works, because 2. It is policy that it works.
Apple didn't "leave the door open" for 3rd party OSes. Apple explicitly engineered 3rd party OS support in, and it is a hard policy requirement that it continue to work.
Publicly documented feature; Openly improved over time; Multiple employees confirm it's for us, not for Apple; Multiple employees confirm it's staying by policy.
https://twitter.com/marcan42/status/1554395176025849856
The Asahai Linux lead Has addressed this directly today.
>Okay, it's been over a year, and it's time to end the nonsense speculation.
I have heard from several Apple employees that:
1. The boot method we use is for 3rd-party OSes, and Apple only use it to test that it works, because 2. It is policy that it works.
Apple didn't "leave the door open" for 3rd party OSes. Apple explicitly engineered 3rd party OS support in, and it is a hard policy requirement that it continue to work.
Publicly documented feature; Openly improved over time; Multiple employees confirm it's for us, not for Apple; Multiple employees confirm it's staying by policy.
https://twitter.com/marcan42/status/1554395176025849856
Important bit:
Apple gives users explicit permission to run their own OS in their EULA.
Apple gives users explicit permission to run their own OS in their EULA.
Indeed, the fact that it even has to do so is the important bit, and reflects the attitude of such companies (and to a certain extent, the government) today.
Booting Apple Silicon has strong cryptographic protections for all of the boot components.
An alternate view on the EULA is that it is a legal statement that nobody can get into trouble with any DCMA stupidity if they want to boot their own OS.
Contrast this with the Playstation 2 debacle, where you were only allowed to boot Sony's Official Linux. Which they then attempted to disable / withdraw when it was used to attack other parts of the Playstation copy protection system.
Apple has also provided a way for ARM Linux VMs to use Rosetta2 for Intel binaries. So they are clearly aware of the wants, needs and usefulness of running other OSs. The cynical might say this was only done to support some internal project that uses Docker, but why put in the effort to make it available to everyone?
The current situation does not preclude providing assistance in the future - Apple still hasn't finished replacing all of the Intel products.
An alternate view on the EULA is that it is a legal statement that nobody can get into trouble with any DCMA stupidity if they want to boot their own OS.
Contrast this with the Playstation 2 debacle, where you were only allowed to boot Sony's Official Linux. Which they then attempted to disable / withdraw when it was used to attack other parts of the Playstation copy protection system.
Apple has also provided a way for ARM Linux VMs to use Rosetta2 for Intel binaries. So they are clearly aware of the wants, needs and usefulness of running other OSs. The cynical might say this was only done to support some internal project that uses Docker, but why put in the effort to make it available to everyone?
The current situation does not preclude providing assistance in the future - Apple still hasn't finished replacing all of the Intel products.
Its not like it would matter if they didn't. It's your hardware.
Tell that to Nintendo.
It’s baffling how outright hostile Nintendo sometimes can be to its most devoted fans. And it’s not even new - they’ve gotten away with it since the moment they stepped into video games.
It’s not baffling at all. That’s what kept them alive.
In Japan the Famicom was open, and it got flooded with junk like the Atari 2600 did. This threatened the same problems as Atari ran into.
The Famicom Disk System relied on a strange copyright check on the physical disks to make them harder to pirate. It worked better than nothing, but not perfectly.
The NES came out after the disk system but before the first mapper chips (which Nintendo controlled tightly for a few years) in 1985. By that time they had been through the problems in Japan and seeing what happened in America with the Atari crash
Nintendo, rightly, knew they couldn’t let it happen again in America. They needed to show their console wouldn’t be full of complete trash, so they used the lockout chip to ensure all publishers had to through them.
It’s a big part of why they were successful and able to reinvigorate the US market. It worked until the chip was cracked later in the console’s lifecycle. But by then the threat passed, the NES was safely ensconced.
They’ve never forgotten that lesson.
(No comment on fans)
In Japan the Famicom was open, and it got flooded with junk like the Atari 2600 did. This threatened the same problems as Atari ran into.
The Famicom Disk System relied on a strange copyright check on the physical disks to make them harder to pirate. It worked better than nothing, but not perfectly.
The NES came out after the disk system but before the first mapper chips (which Nintendo controlled tightly for a few years) in 1985. By that time they had been through the problems in Japan and seeing what happened in America with the Atari crash
Nintendo, rightly, knew they couldn’t let it happen again in America. They needed to show their console wouldn’t be full of complete trash, so they used the lockout chip to ensure all publishers had to through them.
It’s a big part of why they were successful and able to reinvigorate the US market. It worked until the chip was cracked later in the console’s lifecycle. But by then the threat passed, the NES was safely ensconced.
They’ve never forgotten that lesson.
(No comment on fans)
All the best games for the 2600 were by third parties. There were very few good Atari games and none of them came close to the quality of the best third party games. Pretty sure it was Atari's own horrible ET game that sank them, not other companies.
Pretty sure doesn’t cut it. You’re wrong. It wasn’t as easy as OP make it out to be, that the glut of third-party games killed the 2600, but it wasn’t Atari’s own games who cratered the price of a 2600 title and took the whole console market down.
E.T. was just one more line item on a massive list of reasons for why the video game industry imploded on itself with Atari standing pretty much dead center of the blast zone.
> Nintendo, rightly, knew they couldn’t let it happen again in America. They needed to show their console wouldn’t be full of complete trash, so they used the lockout chip to ensure all publishers had to through them.
It wasn’t just about protecting the brand, it was also every bit about collecting money at every single step of the production pipeline. They were able to not only have some better QC, but they were able to literally tell developers “no, you cannot make your game for anyone else. If you do, you’re not allowed to make it for the Nintendo, and that sucks for you because we have ~80% of the market.“
They did it so they could enforce what was functionally a monopoly on the games industry. Sega went to great lengths to undo Nintendo‘s grasp, and ultimately they weren’t even successful - they got a notable carve out of the market but it was still Nintendo’s industry.
It took Sony going on a revenge tour (touting their CD format and wildly generous/unsustainable licensing deals) after Nintendo backstabbed them to finally dethrone Nintendo and end the norm that was their walled garden/top down control of the console games world.
It wasn’t just about protecting the brand, it was also every bit about collecting money at every single step of the production pipeline. They were able to not only have some better QC, but they were able to literally tell developers “no, you cannot make your game for anyone else. If you do, you’re not allowed to make it for the Nintendo, and that sucks for you because we have ~80% of the market.“
They did it so they could enforce what was functionally a monopoly on the games industry. Sega went to great lengths to undo Nintendo‘s grasp, and ultimately they weren’t even successful - they got a notable carve out of the market but it was still Nintendo’s industry.
It took Sony going on a revenge tour (touting their CD format and wildly generous/unsustainable licensing deals) after Nintendo backstabbed them to finally dethrone Nintendo and end the norm that was their walled garden/top down control of the console games world.
On a technical level, you can't install third party OSs without accepting the EULA first. Whether such acceptance has legal meaning, I don't know, and it probably depends on jurisdiction.
> On a technical level, you can't install third party OSs without accepting the EULA first.
You absolutely can (no EULA when booting into recovery partition), and I’m also fairly sure that acceptance would be legally void, as it only applies to the software. The hardware you own, it’s not licensed to you.
And thanks to the first sale doctrine, there’s nothing stopping someone from starting to sell M1/M2 MacBooks running Asahi commercially.
You absolutely can (no EULA when booting into recovery partition), and I’m also fairly sure that acceptance would be legally void, as it only applies to the software. The hardware you own, it’s not licensed to you.
And thanks to the first sale doctrine, there’s nothing stopping someone from starting to sell M1/M2 MacBooks running Asahi commercially.
I base this upon what I read in OP. From OP:
> You do have to click through Apple's EULA in order to use the machines at all.
> Owner control is asserted on first boot (you become machine owner by going through the macOS setup flow and creating the first admin user).
> The SEP maintains a database of machine owner users. The first such user is created when the user goes through the macOS boot flow on first startup from a factory-fresh state (or after a full DFU wipe). Subsequent machine owners can only be created by authenticating with an existing owner's credentials.
> Permissive Security allows for ~all security features to be disabled, and third-party kernels to be installed. No phoning home is required. Downgrading to Permissive Security requires booting in 1TR paired to the specific OS involved, and authenticating using machine owner credentials.
It seems to me that you can boot into the recovery partition but in order to be able to boot Linux, you need to authenticate using machine owner credentials, which you only get if you go through setup of the OS, for which you need to accept the EULA. However, on the good news front, OP also writes that no internet access is required for any of these steps.
> You do have to click through Apple's EULA in order to use the machines at all.
> Owner control is asserted on first boot (you become machine owner by going through the macOS setup flow and creating the first admin user).
> The SEP maintains a database of machine owner users. The first such user is created when the user goes through the macOS boot flow on first startup from a factory-fresh state (or after a full DFU wipe). Subsequent machine owners can only be created by authenticating with an existing owner's credentials.
> Permissive Security allows for ~all security features to be disabled, and third-party kernels to be installed. No phoning home is required. Downgrading to Permissive Security requires booting in 1TR paired to the specific OS involved, and authenticating using machine owner credentials.
It seems to me that you can boot into the recovery partition but in order to be able to boot Linux, you need to authenticate using machine owner credentials, which you only get if you go through setup of the OS, for which you need to accept the EULA. However, on the good news front, OP also writes that no internet access is required for any of these steps.
"On a technical level..."
Sorry, what? Does buying a device from Apple contractually oblige me to turn on the phone and agree to the EULA on "first run"? What about second hand markets?
What if I was smart / tooled up enough to replace the Iphone flash storage with my own OS (without running "first run")?
At what "technical level" would what your saying make any sense? Because it seems far more like a "contractual condition of purchase" (I appear to have made that term up) issue vs a "technical" issue to me.
Sorry, what? Does buying a device from Apple contractually oblige me to turn on the phone and agree to the EULA on "first run"? What about second hand markets?
What if I was smart / tooled up enough to replace the Iphone flash storage with my own OS (without running "first run")?
At what "technical level" would what your saying make any sense? Because it seems far more like a "contractual condition of purchase" (I appear to have made that term up) issue vs a "technical" issue to me.
By technical level I meant that the security chip only allows admin users to change the security level to one that allows booting linux, and in order to create admin users, you need to accept the EULA. Also see my reply to your sibling comment.
How much this mechanism enforced by the SEP can be circumvented with physical access by e.g. desoldering some components and replacing them with alternatives, I don't know. If the SEP is located on the main M1 SoC, you will probably have a hard time though.
Also note that this thread is talking about laptops, not phones.
How much this mechanism enforced by the SEP can be circumvented with physical access by e.g. desoldering some components and replacing them with alternatives, I don't know. If the SEP is located on the main M1 SoC, you will probably have a hard time though.
Also note that this thread is talking about laptops, not phones.
> By technical level I meant that the security chip only allows admin users to change the security level to one that allows booting linux, and in order to create admin users, you need to accept the EULA
Hmm, again a "theory" - its a software limit not a hardware one. If I could pwn apples root account that statement would not hold true (I dont write exploits against Apple, I dont know what's "state of the art").
My initial comment was to point out the fact "at a technical level" is a silly comment, at a "technical level" there is likely to always be > 0 vulnerabilities so you are wrong (hence current Apple root access on Iphones through "jail breaking")
> Also note that this thread is talking about laptops, not phones.
Ironically Iphone is probably harder than a laptop, I moved the goal posts against myself (see latest M1/M2 kernel upstream work as evidence of that) - which I appreciate is annoying, so sorry for that!
Hmm, again a "theory" - its a software limit not a hardware one. If I could pwn apples root account that statement would not hold true (I dont write exploits against Apple, I dont know what's "state of the art").
My initial comment was to point out the fact "at a technical level" is a silly comment, at a "technical level" there is likely to always be > 0 vulnerabilities so you are wrong (hence current Apple root access on Iphones through "jail breaking")
> Also note that this thread is talking about laptops, not phones.
Ironically Iphone is probably harder than a laptop, I moved the goal posts against myself (see latest M1/M2 kernel upstream work as evidence of that) - which I appreciate is annoying, so sorry for that!
This is pretty impressive and a great improvement over the current x86 status quo as far as freedom and security goes.
All that is left is a way to stop the phone home when you need to do a DFU restore if you set up the 'restore server' first as an owner when you first set up the device. I think corporations and other large organizations would find that end to end assurance useful. Also would be part of removing the dependence from apple to do activation locks and MDM for corps and nerds who want full ownership over their devices. Or some sort of offline DFU restore mode for people who need the ability to do airgapped / isolated updates and wipes.
But I also see how that can be leveraged in bad ways by some governments and thieves, so looking at the system balance they chose where a very small lynchpin moment requires phone home is and understandable compromise, even though I don't agree with it fully.. I wonder if the phone home could be done behind VPNs and such, or does it block that?
All that is left is a way to stop the phone home when you need to do a DFU restore if you set up the 'restore server' first as an owner when you first set up the device. I think corporations and other large organizations would find that end to end assurance useful. Also would be part of removing the dependence from apple to do activation locks and MDM for corps and nerds who want full ownership over their devices. Or some sort of offline DFU restore mode for people who need the ability to do airgapped / isolated updates and wipes.
But I also see how that can be leveraged in bad ways by some governments and thieves, so looking at the system balance they chose where a very small lynchpin moment requires phone home is and understandable compromise, even though I don't agree with it fully.. I wonder if the phone home could be done behind VPNs and such, or does it block that?
We should all be grateful for the time and passion the Asahi Linux (AL) team of hackers have invested in documenting (ugh, the most boring job!) and reverse-engineering the Apple Silicon Macs to port Linux to it. If you do plan to buy an Apple Silcon Mac M1 / M2 though, I'd suggest you rather hold off that and instead donate some money to the Asahi Linux team here - https://asahilinux.org/support/ instead. Despite the progress made by the AL team, the simple fact remains that these Apple Mac M1/M2 platforms can only run crippled versions of other OS, and macOS still remains the only usable OS on it. More donations to the AL team can fix this faster, and not buying these Macs will also put pressure on Apple to further delay locking down these systems more and / or (one can dream!) even force them to release more hardware literature to provide bare minimum support for alternate OS development. Donating even a small sum to AL would be money well spent compared to giving your money to a trillion dollar company that isn't bothered to support system developers.
Note that the opaque and closed nature of the Apple Silicon platform (unlike AMD / Intel or other ARM CPUs that support a plethora of OSes and allow their development) hugely constrain our consumer rights, right to repair and computing freedom.
> Definitely worth referencing next time someone on HN or elsewhere claims Apple's trying to lock down their computers to running macOS only.
I do say this often here vocally that with Apple Silicon Apple does plan to lock down the Mac platform in the future. The key point though is that it will happen only once the Apple Silicon Mac platforms reach a critical level of adoption. Technically, it is trivial now for them to lock the bootloader and completely lock down every mac with a firmware update. But commercially it is not yet a viable move for them as the backlash to such a move would generate a lot of bad PR that would hurt the sale and adoption of the ARM Macs. Apple learnt that lesson when they introduced the Mac Minis with soldered RAM and SSDs - it was the worse selling Mac Mini model, and they were forced to step back, slowdown and reintroduce another model with removable RAMs.
The pattern of how Apple has been increasingly locking down the Mac platform is evident:
1. The first few Intel Mac Minis allowed you some level of customisation of both the hardware (change RAM or HDD / SSD) and software (install other full featured OS).
2. Then came the Mac Minis with soldered RAM and SSD. You could no longer customise the hardware. Software was still customisable and you could still install other OSes. (Recall that Apple even offered free drivers for another OS, i.e. Windows).
3. The current generation of M1 Mini now doesn't allow you to customise both the hardware (everything is soldered) and the software. Technically you can install other OSes, but the reality is that currently only crippled versions of Linux and xBSD is available and practically the only full-featured OS that can run on it is still macOS.
With the Apple Silicon ARM chips in the Mac, Apple is now only ONE step away from locking the bootloaders of Apple Silicon Macs any time to make it a completely closed platform like the iPhones / iPads. It has been evident that Apple has been planning this for years. It's the old - https://en.wikipedia.org/wiki/Boiling_frog - trick to lull its users into not realising how their rights are slowly being encroached, while Apple marketing comes up with new ways to sell you the idea that locking down the system is for your own good.
These are very clear indicators of how Apple has been working slowly to lockdown the Mac platform like their ios platforms. The reason for this is simple - BigTech are increasingly moving towards selling everything as a service. Services - https://news.ycombinator.com/item?id=32269915 - are more profitable because it means they create recurring income (even after the device is sold) which means more profits. And Apple's successful business model for this, that earns them billions of dollars, is the closed-platform modelof the iPhones / iPads (which ofcourse, are also powered by the same Apple Silicon but with locked bootloaders). Such closed system also help in planned obsolescence that increase sale.
Note that the opaque and closed nature of the Apple Silicon platform (unlike AMD / Intel or other ARM CPUs that support a plethora of OSes and allow their development) hugely constrain our consumer rights, right to repair and computing freedom.
> Definitely worth referencing next time someone on HN or elsewhere claims Apple's trying to lock down their computers to running macOS only.
I do say this often here vocally that with Apple Silicon Apple does plan to lock down the Mac platform in the future. The key point though is that it will happen only once the Apple Silicon Mac platforms reach a critical level of adoption. Technically, it is trivial now for them to lock the bootloader and completely lock down every mac with a firmware update. But commercially it is not yet a viable move for them as the backlash to such a move would generate a lot of bad PR that would hurt the sale and adoption of the ARM Macs. Apple learnt that lesson when they introduced the Mac Minis with soldered RAM and SSDs - it was the worse selling Mac Mini model, and they were forced to step back, slowdown and reintroduce another model with removable RAMs.
The pattern of how Apple has been increasingly locking down the Mac platform is evident:
1. The first few Intel Mac Minis allowed you some level of customisation of both the hardware (change RAM or HDD / SSD) and software (install other full featured OS).
2. Then came the Mac Minis with soldered RAM and SSD. You could no longer customise the hardware. Software was still customisable and you could still install other OSes. (Recall that Apple even offered free drivers for another OS, i.e. Windows).
3. The current generation of M1 Mini now doesn't allow you to customise both the hardware (everything is soldered) and the software. Technically you can install other OSes, but the reality is that currently only crippled versions of Linux and xBSD is available and practically the only full-featured OS that can run on it is still macOS.
With the Apple Silicon ARM chips in the Mac, Apple is now only ONE step away from locking the bootloaders of Apple Silicon Macs any time to make it a completely closed platform like the iPhones / iPads. It has been evident that Apple has been planning this for years. It's the old - https://en.wikipedia.org/wiki/Boiling_frog - trick to lull its users into not realising how their rights are slowly being encroached, while Apple marketing comes up with new ways to sell you the idea that locking down the system is for your own good.
These are very clear indicators of how Apple has been working slowly to lockdown the Mac platform like their ios platforms. The reason for this is simple - BigTech are increasingly moving towards selling everything as a service. Services - https://news.ycombinator.com/item?id=32269915 - are more profitable because it means they create recurring income (even after the device is sold) which means more profits. And Apple's successful business model for this, that earns them billions of dollars, is the closed-platform modelof the iPhones / iPads (which ofcourse, are also powered by the same Apple Silicon but with locked bootloaders). Such closed system also help in planned obsolescence that increase sale.
One problem with this argument is that you can never be proven wrong. 20 years from now if the platform is still open, there will still be ample evidence that, as Apple tries to maintain security, instead they’re actually preparing to close the platform.
I think if they were going to lock it down, the ARM transition was the perfect opportunity. Half the computing world expected it anyway, and the number of people who care is far fewer than those who just want a robust computer.
But I can effectively never be proven correct.
I think if they were going to lock it down, the ARM transition was the perfect opportunity. Half the computing world expected it anyway, and the number of people who care is far fewer than those who just want a robust computer.
But I can effectively never be proven correct.
> 20 years from now if the platform is still open ...
I am quite willing to concede that Apple doesn't need to lock the bootloader on the Apple Silicon Macs, as long as no viable alternate OSes for it emerges and / or every reverse engineering effort to port and run alternate Oses on it can be countered and hampered by changing the hardware in the next model. So in effect, Apple can continue claiming that Apple Silicons are "open". But how much does this "openness" of Apple Silicon matter when they are only available in custom hardware (the Mac platform) and any change in the hardware means you may not be able to run the OS to use the Apple Silicon CPU / SoC to the full extent? The soldered parts ensure planned obsolescense and limited life anyway for every Apple Silicon Mac. So even if someone manages to reverse engineer one model, it will have a short life, and they will have their work cut out for the next new Apple Silicon with enough hardware modifications to sabotage any serious competing OS.
If Apple really wants it users to believe that Apple Silicon Macs are open, all it has to do is release the drivers for an alternate OS. For all those who claim that it will be an additional unnecessary burden, remember that Apple has done it in the past with Bootcamp and Windows driver. For those who claim that Microsoft cannot offer Windows on Apple Silicon because of their tie-up / contract with Qualcomm, note that there are other alternate OSes too. If Apple doesn't want to release their hardware literature to the public and is comfortable with only working with corporate I can point Apple to IBM or Canonical who make Red Hat Linux / Fedora and Ubuntu OS respectively, and who don't care about including propreitary driver blobs in their distribution (as far as I know).
I am quite willing to concede that Apple doesn't need to lock the bootloader on the Apple Silicon Macs, as long as no viable alternate OSes for it emerges and / or every reverse engineering effort to port and run alternate Oses on it can be countered and hampered by changing the hardware in the next model. So in effect, Apple can continue claiming that Apple Silicons are "open". But how much does this "openness" of Apple Silicon matter when they are only available in custom hardware (the Mac platform) and any change in the hardware means you may not be able to run the OS to use the Apple Silicon CPU / SoC to the full extent? The soldered parts ensure planned obsolescense and limited life anyway for every Apple Silicon Mac. So even if someone manages to reverse engineer one model, it will have a short life, and they will have their work cut out for the next new Apple Silicon with enough hardware modifications to sabotage any serious competing OS.
If Apple really wants it users to believe that Apple Silicon Macs are open, all it has to do is release the drivers for an alternate OS. For all those who claim that it will be an additional unnecessary burden, remember that Apple has done it in the past with Bootcamp and Windows driver. For those who claim that Microsoft cannot offer Windows on Apple Silicon because of their tie-up / contract with Qualcomm, note that there are other alternate OSes too. If Apple doesn't want to release their hardware literature to the public and is comfortable with only working with corporate I can point Apple to IBM or Canonical who make Red Hat Linux / Fedora and Ubuntu OS respectively, and who don't care about including propreitary driver blobs in their distribution (as far as I know).
I've provided an example of how Apple has been locking down the Mac Minis over the years to outright prevent us from customising the hardware, to now crippling our ability to run the system softwares that we want.
You can definitely claim that these are measures that Apple has taken to harden the "security" of the Macs - a hardware that cannot be modified and system software that cannot be easily replaced does add to a device's security. But from that perspective, an open bootloader is clearly a security threat too. When Apple locks the bootloaders on the Mac tomorrow, and claims it is to make the device more "secure" it would be true! But then, why stop there - now that the system software is "secure" from tampering, why not also extend this "security" to other softwares that will be run on the Mac? The "secure" solution is obvious - allow the softwares to be only be installed from the Apple App Store. Now the Mac is as "secure" as your iPhones and iPads!
Are you claiming this won't happen - that Macs will never be locked down machines like the iDevices? What indications have Apple given that suggests this? (Remember, they have already taken away our ability to customise or repair the hardware, and crippled our ability to run the software we want on it).
> I think if they were going to lock it down, the ARM transition was the perfect opportunity.
No, the amount of bad PR it would have generated would have tarnished the Apple Silicon branding, and all the polarised debates and the negativity it would have generated would have taken away focus from the good features of the SoC. It would definitely have reduced the sales of the M1 Mac devices, and that would have made the shareholders jittery too. Let's not forget that Apple (and others) who want to push such locked down systems in the personal and professional computing field face an uphill task to change consumer behaviour - we consumers are used to, and expect to be allowed to tinker with our hardware and software. Apple (and others) obviously cannot change that expectation overnight, and hence the slow phased approach of eroding our consumer rights and computing freedom is the only way to achieve their goal.
You can definitely claim that these are measures that Apple has taken to harden the "security" of the Macs - a hardware that cannot be modified and system software that cannot be easily replaced does add to a device's security. But from that perspective, an open bootloader is clearly a security threat too. When Apple locks the bootloaders on the Mac tomorrow, and claims it is to make the device more "secure" it would be true! But then, why stop there - now that the system software is "secure" from tampering, why not also extend this "security" to other softwares that will be run on the Mac? The "secure" solution is obvious - allow the softwares to be only be installed from the Apple App Store. Now the Mac is as "secure" as your iPhones and iPads!
Are you claiming this won't happen - that Macs will never be locked down machines like the iDevices? What indications have Apple given that suggests this? (Remember, they have already taken away our ability to customise or repair the hardware, and crippled our ability to run the software we want on it).
> I think if they were going to lock it down, the ARM transition was the perfect opportunity.
No, the amount of bad PR it would have generated would have tarnished the Apple Silicon branding, and all the polarised debates and the negativity it would have generated would have taken away focus from the good features of the SoC. It would definitely have reduced the sales of the M1 Mac devices, and that would have made the shareholders jittery too. Let's not forget that Apple (and others) who want to push such locked down systems in the personal and professional computing field face an uphill task to change consumer behaviour - we consumers are used to, and expect to be allowed to tinker with our hardware and software. Apple (and others) obviously cannot change that expectation overnight, and hence the slow phased approach of eroding our consumer rights and computing freedom is the only way to achieve their goal.
> We should all be grateful for the time and passion the Asahi Linux (AL) team of hackers have invested in documenting (ugh, the most boring job!)
I assure you that if the team found this to be incredibly boring they would not be doing it.
I assure you that if the team found this to be incredibly boring they would not be doing it.
Tinkering and reverse engineering is fun, but most open source developers don't put in much effort into documenting their research and final product because they consder it an additional chore (which it is - writing documents that others can understand requires effort and time).
Apple is playing coy. Their stance is probably something like "Macs are designed to run macOS... but yeah, this is our general purpose computer line and we can't afford the PR hit we'd get by locking them down. Yet."
This is bonkers paranoid. Don’t ask me, reference the article linked above by one of the most prominent Linux distros on aarch64 Macs. The author is clearly qualified when clearly stating that the stance is not this nefarious.
Not only a PR hit. We now have legislation that will force Apple to open up their iPhone. Your cynical take that Apple is waiting to do it is a mistake; they’re losing control of the iPhone as we speak because they locked it down too much.
Were that their attitude they’d be doing less to make it possible today.
You can't have a good development machine that is locked down. As long as Apple wants people to write software they will have to have at least one open platform.
That’s just not true. Tons of people use a Mac as a software development machine and virtually zero of them install a non-macOS operating system.
All it has to do is run Docker and people will continue developing Linux software on it.
That said I don’t think Apple is planning on locking down macs, simply because they have never done so (at least not in the modern era), whereas they have always done so with i-devices. Sure there’s always a chance they could change one practice or the other but there’s no good reason to believe they will.
All it has to do is run Docker and people will continue developing Linux software on it.
That said I don’t think Apple is planning on locking down macs, simply because they have never done so (at least not in the modern era), whereas they have always done so with i-devices. Sure there’s always a chance they could change one practice or the other but there’s no good reason to believe they will.
Coming in as an Apple skeptic, I’m fairly impressed in the balance Apple has done between user security and device openness. This definitely sounds like a well designed architecture.
The other Apple Silicon tidbit today from Linus Torvalds in his Linux 5.19 release notes:
>On a personal note, the most interesting part here is that I did the release (and am writing this) on an arm64 laptop. It's something I've been waiting for for a _loong_ time, and it's finally reality, thanks to the Asahi team. We've had arm64 hardware around running Linux for a long time, but none of it has really been usable as a development platform until now.
Not that I've used it for any real work, I literally have only been doing test builds and boots and now the actual release tagging. But I'm trying to make sure that the next time I travel, I can travel with this as a laptop and finally dogfooding the arm64 side too.
https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...
>On a personal note, the most interesting part here is that I did the release (and am writing this) on an arm64 laptop. It's something I've been waiting for for a _loong_ time, and it's finally reality, thanks to the Asahi team. We've had arm64 hardware around running Linux for a long time, but none of it has really been usable as a development platform until now.
Not that I've used it for any real work, I literally have only been doing test builds and boots and now the actual release tagging. But I'm trying to make sure that the next time I travel, I can travel with this as a laptop and finally dogfooding the arm64 side too.
https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...
[deleted]
How does one even begin to start learning about this subject? This is quite fascinating, I've always wanted to learn about OSes, the underlying mechanisms... all of that. The sheer depth of knowledge and technical-know how is truly incredible. I find it hard to even begin, there's so many resources out there.
Some college CS departments have courses in OS development. If that's not an option, I'd start with a textbook like Operating Systems: Design & Implementation, aka the Minix book, since it documents the development of the Minix operating system.
https://wiki.minix3.org/doku.php?id=www:documentation:start
https://wiki.minix3.org/doku.php?id=www:documentation:start
Generally you’d look to learn about OS design and reverse engineering.
For a hands-on introduction, writing a minimal kernel in Rust, see https://os.phil-opp.com/
The OSDev wiki is nice.
https://wiki.osdev.org/
https://wiki.osdev.org/
Is there any value in Asahi Linux given GPU won't be likely supported for the next 10+ years (based on how long it took for regular Linux to get decent Nvidia and Radeon open source drivers and those didn't rely on any crypto chips)? It seems like a nice toy project without much value.
You can still boot the os and browse the internet right? Seems viable as a dev laptop.
How does it compare in terms of "philosophical freedom" compared to intel IME? Does it need many binary blobs?
> This puts them somewhere between x86 PCs and a libre-first system like the Talos II in terms of freedom to replace firmware and boot components; while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even old ThinkPads).
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl... - list of firmware blobs
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl... - list of firmware blobs
Pretty well outlined here: https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
> while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even old ThinkPads).
> while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even old ThinkPads).
Compared to the iME, not much, since at least the secure enclave subsystem won't run any non-Apple code. The scary difference about the iME is that it is directly connected to the network.
Intel ME is not connected to the network. Intel AMT (vPro) is. You have to pay extra to get it, and there are extra conditions to be fulfilled (LAN or Wifi must be Intel).
The difference wrt. Apple Silicon is, that AS firmware blobs run on separate chips and 1) cannot access the main memory freely; they are gated behind IOMMU and 2) there's no SMM equivalent for any of them, so the main CPU time cannot be stolen by firmware.
The difference wrt. Apple Silicon is, that AS firmware blobs run on separate chips and 1) cannot access the main memory freely; they are gated behind IOMMU and 2) there's no SMM equivalent for any of them, so the main CPU time cannot be stolen by firmware.
100% this
Eh, I'd say the differences go deeper than that. Secure Enclave doesn't appear to have any special access to other resources on the system (like memory), it's initialized by the operating system, not by pre-boot firmware, and the rest of the system works perfectly fine if you leave the SEP uninitialized.
What is the source for the "Design Goals for AS Macs"? Has Apple or their engineers advertised these?
Certainly the "Open to other OSes" goal seems to contradict much of their trend from the past few years. (and the very same page later goes on to say "...as long as they behave like macOS")
Certainly the "Open to other OSes" goal seems to contradict much of their trend from the past few years. (and the very same page later goes on to say "...as long as they behave like macOS")
"Apple's approach to third-party OSes is essentially "have fun". We do not have any expectations of direct support, documentation, or additional development effort from them, nor do we expect them to attempt to hinder third-party OSes in any deliberate way. They have explicitly developed the ability to securely run third-party OSes and bootloaders on these machines, and left the rest to us."
Under the list at https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
Under the list at https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
That still sounds like an assumption from the community. Perhaps the "third party OSes and bootloaders" is just a side-effect of Apple's own development requirements.
On the other hand: "Apple gives users explicit permission to run their own OS in their EULA." I guess I haven't read their EULA!
On the other hand: "Apple gives users explicit permission to run their own OS in their EULA." I guess I haven't read their EULA!
It's definitely a bit of a reach. Apple has always given users explicit permission to run their own OS, as far as I understand it. Bootcamp has existed for years, and before that there was nothing stopping you from putting Linux on a Macbook (besides the loathesome touch bar).
The closest Apple has come to acknowledging third-party OSes on Apple Silicon was their statement that Microsoft is welcome to try porting Windows to it, if they want. I think Asahi sideliners (and Apple fans at large) are quick to attribute mysterious coincidences as benevolence, but I reckon they're making the same mistake that happened when they trusted Microsoft as bedfellows with the open source community. Apple is not your friend, they just make more money if it seems that way.
The closest Apple has come to acknowledging third-party OSes on Apple Silicon was their statement that Microsoft is welcome to try porting Windows to it, if they want. I think Asahi sideliners (and Apple fans at large) are quick to attribute mysterious coincidences as benevolence, but I reckon they're making the same mistake that happened when they trusted Microsoft as bedfellows with the open source community. Apple is not your friend, they just make more money if it seems that way.
There is absolutely no reason Apple couldn’t have locked things down quite a bit further. The other OS functionality is totally unnecessary for MacOS or probably even Apple tools their store/repair techs use.
They don’t allow any of this on iOS devices, and M1/2 Macs are basically iOS devices at a hardware level with more ports/power. Surely allowing the other OS functionality is at least a tiny security weakness because it makes it easier to get a foothold to attack from. Apple takes security really seriously, and has only been getting stricter.
I just have a hard time seeing any reason any of this exists unless they purposefully chose to allow it. It’s can’t be happenstance.
They don’t allow any of this on iOS devices, and M1/2 Macs are basically iOS devices at a hardware level with more ports/power. Surely allowing the other OS functionality is at least a tiny security weakness because it makes it easier to get a foothold to attack from. Apple takes security really seriously, and has only been getting stricter.
I just have a hard time seeing any reason any of this exists unless they purposefully chose to allow it. It’s can’t be happenstance.
> The other OS functionality is totally unnecessary for MacOS or probably even Apple tools their store/repair techs use.
Both of those statements are probably true, but it's not the same for hardware calibration/testing from the factory. It totally makes sense that Apple would add this as a convenient way to use a single testing image for multiple Macs, or as an entrypoint for Microsoft to start supporting Bootcamp. Hell, maybe it was a mistake and they're too embarassed to admit. Apple doesn't have that kind of dialogue with their community though, so we don't know. Until they release a statement acknowledging that they made this change for Asahi, nobody can say they're "helping" with any certainty.
> Surely allowing the other OS functionality is at least a tiny security weakness because it makes it easier to get a foothold to attack from.
Not really? You should go check out the boot flow on the link in this thread, I can't really conceive of any way that an attacker could abuse that process. Sure you might be able to boot malicious software, but you're not going to get it to persist (certainly not in MacOS), and it can't really read any sensitive information since your APFS volume is still encrypted. There's effectively no security tradeoff to their implementation, particularly for MacOS users.
> I just have a hard time seeing any reason any of this exists unless they purposefully chose to allow it. It’s can’t be happenstance.
I agree. I just don't think it was done for Asahi, and it certainly doesn't seem like deliberate help.
Both of those statements are probably true, but it's not the same for hardware calibration/testing from the factory. It totally makes sense that Apple would add this as a convenient way to use a single testing image for multiple Macs, or as an entrypoint for Microsoft to start supporting Bootcamp. Hell, maybe it was a mistake and they're too embarassed to admit. Apple doesn't have that kind of dialogue with their community though, so we don't know. Until they release a statement acknowledging that they made this change for Asahi, nobody can say they're "helping" with any certainty.
> Surely allowing the other OS functionality is at least a tiny security weakness because it makes it easier to get a foothold to attack from.
Not really? You should go check out the boot flow on the link in this thread, I can't really conceive of any way that an attacker could abuse that process. Sure you might be able to boot malicious software, but you're not going to get it to persist (certainly not in MacOS), and it can't really read any sensitive information since your APFS volume is still encrypted. There's effectively no security tradeoff to their implementation, particularly for MacOS users.
> I just have a hard time seeing any reason any of this exists unless they purposefully chose to allow it. It’s can’t be happenstance.
I agree. I just don't think it was done for Asahi, and it certainly doesn't seem like deliberate help.
Yeah I’ve read how the boot works, and in theory if it all works perfectly then they should be 100% irrelevant.
What we know software has bugs. And it seems like if you can execute kernel level code on the machine, you’re more likely to be able to find one of those bugs somehow from the other 0S then you would if you were having to attack from a macOS process.
Total 100% assumption on my part.
Apple knows what happens. No matter what they do someone was going to try and put Linux or BSD on the machine. That plus the way things are setup makes me suspect Apple is purposely allowing this in the closest to a wink-wink-nudge-nudge approval they’ll ever give us.
What we know software has bugs. And it seems like if you can execute kernel level code on the machine, you’re more likely to be able to find one of those bugs somehow from the other 0S then you would if you were having to attack from a macOS process.
Total 100% assumption on my part.
Apple knows what happens. No matter what they do someone was going to try and put Linux or BSD on the machine. That plus the way things are setup makes me suspect Apple is purposely allowing this in the closest to a wink-wink-nudge-nudge approval they’ll ever give us.
Look at their decision to remove all the scripting languages from macOS as another example. At first glance, this could mean a terrible step back for openness but the reality is sunnier. Apple has widely seen that everybody’s using Homebrew and no one is calling their old and crusty language versions anymore. So they wisely decided to count on the open-source community, who’s doing a better job at this than them, and to leave space for Homebrew to finally put references in your path to the languages you install.
Everybody wins by Apple giving a bit more space to others.
Everybody wins by Apple giving a bit more space to others.
Apple has advertised this about as explicitly as they could possibly do so without saying it publicly.
I suppose Apple's public announcements are tightly controlled, so perhaps the string of clues is as much as the engineers behind this could get out.
> You do have to click through Apple's EULA in order to use the machines at all.
Someone does. You can walk up to a Mac at a friends house and use it without accepting any EULA.
The machine doesn't physically check who accepted the EULA.
You can do everything without ever accepting a EULA yourself.
Someone does. You can walk up to a Mac at a friends house and use it without accepting any EULA.
The machine doesn't physically check who accepted the EULA.
You can do everything without ever accepting a EULA yourself.
I wonder if anyone at Apple is working on this secretly.
I sure hope not, as it would compromise all the legitimate reverse engineering being done on it.
There's an important distinction to be made between helping to make it work (e.g. explaining how the bootloader is implemented, or perhaps offering occasional code bug fixes) and directly revealing Apple intellectual property by supplying internal documentation or code written with the knowledge of internal documentation.
I'm sure there are people at Apple itching to provide documentation for things like the GPU. But given the minefield which is GPU patents I honestly don't blame Apple for deciding there's insufficient upside to revealing anything they don't have to.
I'm sure there are people at Apple itching to provide documentation for things like the GPU. But given the minefield which is GPU patents I honestly don't blame Apple for deciding there's insufficient upside to revealing anything they don't have to.
"Compromise"? "Legitimate"?
"clean room" reverse engineering really benefits from the room being clean. I'm not sure how much this applies to Asahi's efforts, but if you're working on reactos or wine, having been exposed to microsoft's source makes you tainted.
So to bulk out the grandparent's claim - I'd really like if there was an internal effort that was sanctioned on a "keep our name out of it" grounds.
So to bulk out the grandparent's claim - I'd really like if there was an internal effort that was sanctioned on a "keep our name out of it" grounds.
But why would that be a concern? Why isn't Apple's involvement welcomed for the expertise, rather than maligned for some arbitrary notion of "cleanliness" in the process?
If Apple was open about it and willing to license stuff as necessary, it would be fine.
But they’re not. We know that because they aren’t doing it.
So if an Apple employee were to contribute anything it would be some sort of license violation and taint the kernel’s licensing and the (legal) safety of the project.
To the degree Apple is involved in this, it can’t be more than “benevolent neglect” of allowing this to happen and setting things up in such a way that it’s possible in the first place. They are never going to answer questions or give any source code.
But they’re not. We know that because they aren’t doing it.
So if an Apple employee were to contribute anything it would be some sort of license violation and taint the kernel’s licensing and the (legal) safety of the project.
To the degree Apple is involved in this, it can’t be more than “benevolent neglect” of allowing this to happen and setting things up in such a way that it’s possible in the first place. They are never going to answer questions or give any source code.
Ah I see. I had understood the Apple employee participating surreptitiously as them doing so outside of their employment contract (outside of working hours, not on company property, etc.) so was confused about why such contributions would be banned.
At-will employment contracts typically do not have exemptions for "outside of working hours" or "not on company property". They apply 100% of the time, when legally permissible.
My understanding is that nobody dares to do that -- Apple is likely to immediately terminate their employment if they found out about it
Well the trick is not getting found out which isn’t particularly difficult.
Given the incredibly specialized knowledge that Apple employee would have I think it would be pretty easy to find them fast.
There are just very very few people in the world who know the full secrets of how this stuff works.
There are just very very few people in the world who know the full secrets of how this stuff works.
Why is everyone so incredibly cynical. Is it possible Apple did this because they thought it made "business sense". The same reason they do anything else.
A lot of things make business sense that aren't good for users/customers or people in general. It making good business sense isn't sufficient reason to judge it as good or justified.
Years of observation and experience. What makes business sense to Apple (or anyone) is not always in the user's best interest.
According to who? You don’t have perfect information to know the reasons.
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...