Running Linux on Apple Silicon

[theMarble]

So on pre-T2 Mac's, we've been able to natively multi-boot with Linux. Then with the T2 chips, you could still multi-boot Linux if you turned off the Secure Boot option in Recovery Mode. How do you think multi-boot would work with Apple Silicon, if at all? It seems that Apple is killing off Bootcamp in favor of Virtualization, but surely there should be a hacked way to get Linux running. Linux can run on ARM CPU's so it is the case of figuring out a way to get bridgeOS (the base behind T2 and multi-boot) to allow booting of (if we use console hacking terms) unsigned code. Do you think they changed the bridgeOS firmware on Apple Silicon (other than porting it) to not allow unsigned code to run at boot?

I think a bit of reverse engineering will be required as we don't have iDevices as a starting point. Even though it's a semi-custom architecture, under the hood it's just ARM.

 

[MandiMac]

Yeah, but no. Virtualization is the way forward, and hacking around could probably mess up your Mac installation. It's too early to give any indicators in any direction right now, but I think if you need Linux that bad you should get your own machine or a VM.

casperes1996 clearly has more info than me. Thanks!

 

[casperes1996]

Nothing to reverse engineer or figure out. The boot menu is a bit different on Apple Silicon but you can still disable OS verification on boot and install Linux natively - Apple have literally said this themselves in one of the WWDC talks on AS, though I forget which one

 

[Yebubbleman]

So on pre-T2 Mac's, we've been able to natively multi-boot with Linux. Then with the T2 chips, you could still multi-boot Linux if you turned off the Secure Boot option in Recovery Mode. How do you think multi-boot would work with Apple Silicon, if at all? It seems that Apple is killing off Bootcamp in favor of Virtualization, but surely there should be a hacked way to get Linux running. Linux can run on ARM CPU's so it is the case of figuring out a way to get bridgeOS (the base behind T2 and multi-boot) to allow booting of (if we use console hacking terms) unsigned code. Do you think they changed the bridgeOS firmware on Apple Silicon (other than porting it) to not allow unsigned code to run at boot?

I think a bit of reverse engineering will be required as we don't have iDevices as a starting point. Even though it's a semi-custom architecture, under the hood it's just ARM.

It would require the developers of the Linux distro to write drivers (and a bootloader) that works with Apple Silicon hardware. Apple is very unlikely to open this up to developers (seeming to prefer a virtualization-only approach). Whereas, even with a T2 chip, Intel Macs still use the UEFI standard also present on other modern x86-64 based systems, thereby allowing third party OSes to load.

It's possible that Apple may allow an Apple Silicon version of Boot Camp, though, that would likely be nothing like it is on Intel Macs and would likely be through exclusive collaboration with Microsoft. If it came to that, I could easily imagine them trying to partner with Canonical (though Canonical doesn't have a non-server version of Ubuntu for ARM64 just yet), though I can't imagine support or enablement of this would expand past that point.

At best, we may see the advent of a Yellow Dog type Linux version specifically for Apple Silicon Macs (just as Yellow Dog was specifically for PowerPC Macs). Otherwise, it sounds like virtualization via Parallels or any other Apple Silicon compatible hypervisor that ties into Apple's own native hypervisor is going to be how we get Linux running on Apple Silicon Macs (though it would seem to be limited to ARM64-native distros).

 

[Icelus]

They don't support it officially:

Nothing to reverse engineer or figure out. The boot menu is a bit different on Apple Silicon but you can still disable OS verification on boot and install Linux natively - Apple have literally said this themselves in one of the WWDC talks on AS, though I forget which one

Craig Federighi said "no" in a WWDC, but this may refer to the question (Boot Camp) and to any alternative OS.

 

[leman]

Nothing to reverse engineer or figure out. The boot menu is a bit different on Apple Silicon but you can still disable OS verification on boot and install Linux natively - Apple have literally said this themselves in one of the WWDC talks on AS, though I forget which one

Did they? All I remember them saying is that one would use virtualization for running Linux. Then again, there has apparently been some limited success in running Linux on an iPhone, so never say never...

At any rate, even if someone manages to hack the system to boot Linux, it will most likely be useless for any practical purpose. Without drivers etc. all you'll get is a semi-functional prompt.

 

[deconstruct60]

Nothing to reverse engineer or figure out. The boot menu is a bit different on Apple Silicon but you can still disable OS verification on boot and install Linux natively - Apple have literally said this themselves in one of the WWDC talks on AS, though I forget which one

Errr, technically not true. That is distortion of what Apple said.


"...
On Apple Silicon Macs, the boot process is based on Secure Boot architecture of iOS and iPadOS.

Secure Boot ensures that each start-up component is cryptographically signed by Apple and that the boot happens only after the verification of the chain of trust.

This offers much stronger security at boot time on macOS.

In addition, we have added support to boot from multiple macOS installed on internal or external volumes, as well as enabled booting any version of macOS signed by Apple
.

This will allow future macOS to continue booting older versions.

Lastly, we have introduced new macOS Recovery flows. So how does start-up on Apple Silicon Macs work? ...
..."

Explore the new system architecture of Apple silicon Macs - WWDC20 - Videos - Apple Developer

Discover how Macs with Apple silicon will deliver modern advantages using Apple's System-on-Chip (SoC) architecture. Leveraging a unified...

developer.apple.com

Fundamentally Apple Silicon Macs boot like iPhone/iPad Pro do with some Mac extensions to the process. All the extensions are only around macOS. Mac are less locked down that iPhones/iPads, but they are still locked into Apple's proprietary boot process. The other major extension past iPhone/iPads is that you can boot macOS off of an external disk. ( this can be done even in the "full security mode" . So Apple Silicon Macs will boot by default off of secure external OS images. Something the T2 Macs didn't do by default. )

At about 18:00 into the video
"...

Next, Startup Disk.

macOS Recovery Startup Disk focuses on selecting the security policy for each of the volume with macOS installed. You can choose from full or reduced security, as shown here.

... "

Namely

Apple Silicon Macs to Feature New Boot and Recovery Interface, New Mac Sharing Mode Replacing Target Disk Mode

Apple Silicon Macs will introduce a new system for accessing macOS recovery and security options at startup, Apple explained at a WWDC session on...

www.macrumors.com

The "Reduced" security still has to have been overtly signed by Apple to run. That is different the the "ignore signatures completely mode" of T2. This is closer to "look but don't enforce".

There is a point where the Apple engineer makes a somewhat vague reference to the Mac staying the same.

"...

By contrast, reduced security provides flexibility and configurability of your Mac, and it keeps the Mac what it is.

..."

That is about keeping the Mac the same as it is now as being a Mac. ( not following iPhone/iPads into the zone where Apple can kill off your older OS instance because dropped the signatures on it. ) That has little to do with not trying to be a Mac at all. (i.e., trying to maximize non Mac features. Apple Silicon is primarily out to make a Mac more of a Mac; not less. )




There is some huge implicit inferencing and/or generalization here that somehow Apple is going to get into the "signed by Apple" business for Linux and Windows. Don't hold your breath. There is a decent chance there is no UEFI here at all. If that is the case then Apple has no intention of being "open". All the handling would be done through virtual machines that have a virtualized , "open" boot environment that isn't directly on "raw" hardware.
[automerge]1601480158[/automerge]

 

[leman]

There is some huge implicit inferencing and/or generalization here that somehow Apple is going to get into the "signed by Apple" business for Linux and Windows. Don't hold your breath. There is a decent chance there is no UEFI here at all. If that is the case then Apple has no intention of being "open". All the handling would be done through virtual machines that have a virtualized , "open" boot environment that isn't directly on "raw" hardware.

Great summary! I have no doubt whatsoever that Apple Silicon Macs won't have UEFI. It adds additional complexity and vulnerability, slows things down and offers absolutely no benefit on a pre-built system like the Mac.

 

[deconstruct60]

So on pre-T2 Mac's, we've been able to natively multi-boot with Linux. Then with the T2 chips, you could still multi-boot Linux if you turned off the Secure Boot option in Recovery Mode. How do you think multi-boot would work with Apple Silicon, if at all? It seems that Apple is killing off Bootcamp in favor of Virtualization, but surely there should be a hacked way to get Linux running. Linux can run on ARM CPU's so it is the case of figuring out a way to get bridgeOS (the base behind T2 and multi-boot) to allow booting of (if we use console hacking terms) unsigned code. Do you think they changed the bridgeOS firmware on Apple Silicon (other than porting it) to not allow unsigned code to run at boot?

Pretty good chance there is no "bridgeOS".

The T2 Macs boot into iBoot first. ( BridgeOS gets running on the T2 ). Then the T2 provides a copy of the UEFI firmare to the x86 processor. See Figure 3 here ( page 8-9).

Apple Silicon Macs are also going to boot first into iBoot. Then there is a pretty good chance they will boot into something that is not bridgeOS at all. BridgeOS was the OS for the ARM processor subsystem. On the Apple Silicon Macs that is the main processor already ( or at least in the Main processor die/package). There is probably a secure enclave/events/system management processor, but it isn't really doing much "bridging". I suspect there is some shim that I'd would label "mBoot" with encapsulates the differences between macOS boot and iPhone/iPad boot. Finding the external macOS images on external drives ( iPhone only have internal drivers). The reduced security option etc. It is somewhat just a modification of iBoot, but distinct to keep the code management neater.

THere is a chance that Apple is handing off to an extremely locked down super secure mode UEFI image but that doesn't line up at all with the comments with Craig Federighi commentary after WWDC linked in the article above or if look unbiasedly and closely at the WWDC coverage ( apple makes zero mention of boot other operating systems ).
[ Part of the reason why the T2 ships in lock down external mode is probably due to Apple's dissatisfaction with UEFI. ]
If UEFI isn't there that is big blow to raw booting something else.

This "mBoot" jobs is basically just to load up some macOS. Apple also has a "System Recovery" macOS image on the disk now. That may actually serve as the foundation of the unified boot/login screen. ( also discussed in the WWDC session linked above). That screen has accelerated graphics and is s "mac beautiful" . [ that really does not sound like UEFI and sounds lots more like loaded up a highly stripped down MacOS image with macos graphics drivers .] I don't have definiate concrete evidence but I would not be shocked at all if the user interaction level boot "firmware" is actually just macOS. That super stripped down macOS just does a handoff to another macOS to get to the normal image that users interact with.

I think a bit of reverse engineering will be required as we don't have iDevices as a starting point. Even though it's a semi-custom architecture, under the hood it's just ARM.

Not sure that is going to work. If Apple hides the system image and authenticates it before loading ( protect it like they protect the primary UEFI copy on the T2. ) then it will be really hard to disrupt the loading process.

Folks have pointed to hackery where add some old style kernel extension that then proceeds to "eat" the rest of the MacOS kernel to push some rogue boot manager into taking over the primary CPU cores. That's dubious too with Apple Silicon feature of making the kernel space code read only after loading. At some point kernel extensions may go completely away.

Is it going to be impossible? Maybe not over an extended period of time but it will probably take far more 'work' than it is work for anyone who wants to boot Linux (or Windows) for solid, stable production work.

For a large fraction of Linux / Windows workloads virtualization probably won't make a significant performance difference. If Apple adds graphics stack hardware virtualization support to the mix , then an even larger fraction.
OS guests on a slimmed down hypervisor macOS with controlled but essentially direct access to physical GPU and networking aren't going to be much of a major issue. (except for purists and "princess and the pea" performance workloads sensitivity. )

 

[deconstruct60]

....

It's possible that Apple may allow an Apple Silicon version of Boot Camp, though, that would likely be nothing like it is on Intel Macs and would likely be through exclusive collaboration with Microsoft. If it came to that, I could easily imagine them trying to partner with Canonical (though Canonical doesn't have a non-server version of Ubuntu for ARM64 just yet), though I can't imagine support or enablement of this would expand past that point.

At best, we may see the advent of a Yellow Dog type Linux version specifically for Apple Silicon Macs (just as Yellow Dog was specifically for PowerPC Macs). ..

Possible; just not probable. Apple has had about 3 years of the T2 era and has not dipped their toe into the "sign other people's OS images " business at all. If they were going to ramp up on that there probably would have been preparatory movements by now. (similar to moves of getting rid of 32-bit x86 when not going to support them at all on Apple Silicon Macs. etc. )

If Apple adds IOMMU , "pass through" to their hypervisor for GPU and networking there would be Microsoft and customized linux adjustments to the more directly exposed subsystems ( need apple specific drivers ) , but more than decent chance Apple isn't going to let those other OS images grab complete control of the system.

Apple Silicon Macs aren't going to be the only ARM based virtualization targets for ARM cod Linux/Windows OS images. Amazon AWS has a dramatically growing ARM OS hosting business ramping up. Microsoft's Azure is at earlier stages of growth but on the same bandwagon. All the large players are putting something into play.
All the OS implementors need to play nice with ARM virtualized environments so Apple isn't asking them to do anything extraordinarily difficult.

Also the current context isn't like it was in 2005-2006. Macs are not a 'small fish" jumping into a massively bigger pond of deeply entrench "whale" ( windows on x86 ). Linux and Windows are players on ARM. Linux more so as a proxy though Android, but straight Linux also. Apple already has a very major OS player on ARM ( iOS / iPad OS). It is a more of an even playing field race this time (more balkanizsed ). It is a much more strategically important to move their own stuff forward than to divert resources to helping the other options keep up on Mac hardware.

There are not massive hoards of windows on ARMs users out there who have to supply a "safety net" to because are nervous about optionally backing completely out of running macOS. On T2 Macs and going forward completely abandoning macOS on a Mac is not prudent. ( some of the basic boot security is hooked to running some variation of a macOS image.). that is only going to get into a deeper , more interwined relationship with the Apple Silicon Macs going forward.

 

[casperes1996]

They don't support it officially:

Craig Federighi said "no" in a WWDC, but this may refer to the question (Boot Camp) and to any alternative OS.

Did they? All I remember them saying is that one would use virtualization for running Linux. Then again, there has apparently been some limited success in running Linux on an iPhone, so never say never...

At any rate, even if someone manages to hack the system to boot Linux, it will most likely be useless for any practical purpose. Without drivers etc. all you'll get is a semi-functional prompt.

Errr, technically not true. That is distortion of what Apple said.


"...
On Apple Silicon Macs, the boot process is based on Secure Boot architecture of iOS and iPadOS.

Secure Boot ensures that each start-up component is cryptographically signed by Apple and that the boot happens only after the verification of the chain of trust.

This offers much stronger security at boot time on macOS.

In addition, we have added support to boot from multiple macOS installed on internal or external volumes, as well as enabled booting any version of macOS signed by Apple
.

This will allow future macOS to continue booting older versions.

Lastly, we have introduced new macOS Recovery flows. So how does start-up on Apple Silicon Macs work? ...
..."

Explore the new system architecture of Apple silicon Macs - WWDC20 - Videos - Apple Developer

Discover how Macs with Apple silicon will deliver modern advantages using Apple's System-on-Chip (SoC) architecture. Leveraging a unified...

developer.apple.com

Fundamentally Apple Silicon Macs boot like iPhone/iPad Pro do with some Mac extensions to the process. All the extensions are only around macOS. Mac are less locked down that iPhones/iPads, but they are still locked into Apple's proprietary boot process. The other major extension past iPhone/iPads is that you can boot macOS off of an external disk. ( this can be done even in the "full security mode" . So Apple Silicon Macs will boot by default off of secure external OS images. Something the T2 Macs didn't do by default. )

At about 18:00 into the video
"...

Next, Startup Disk.

macOS Recovery Startup Disk focuses on selecting the security policy for each of the volume with macOS installed. You can choose from full or reduced security, as shown here.

... "

Namely

Apple Silicon Macs to Feature New Boot and Recovery Interface, New Mac Sharing Mode Replacing Target Disk Mode

Apple Silicon Macs will introduce a new system for accessing macOS recovery and security options at startup, Apple explained at a WWDC session on...

www.macrumors.com

The "Reduced" security still has to have been overtly signed by Apple to run. That is different the the "ignore signatures completely mode" of T2. This is closer to "look but don't enforce".

There is a point where the Apple engineer makes a somewhat vague reference to the Mac staying the same.

"...

By contrast, reduced security provides flexibility and configurability of your Mac, and it keeps the Mac what it is.

..."

That is about keeping the Mac the same as it is now as being a Mac. ( not following iPhone/iPads into the zone where Apple can kill off your older OS instance because dropped the signatures on it. ) That has little to do with not trying to be a Mac at all. (i.e., trying to maximize non Mac features. Apple Silicon is primarily out to make a Mac more of a Mac; not less. )




There is some huge implicit inferencing and/or generalization here that somehow Apple is going to get into the "signed by Apple" business for Linux and Windows. Don't hold your breath. There is a decent chance there is no UEFI here at all. If that is the case then Apple has no intention of being "open". All the handling would be done through virtual machines that have a virtualized , "open" boot environment that isn't directly on "raw" hardware.
[automerge]1601480158[/automerge]

So thanks for adding these first party sources guys - I may indeed have misremembered something - the WWDC talk referenced here, I believe was what I was remembering, but I could've sworn there was a line in there that explicitly talked about booting a Debian ARM - guess that was just something my brain cooked up. Wasn't out to mislead or anything.

Cheers

 

[Icelus]

So thanks for adding these first party sources guys - I may indeed have misremembered something - the WWDC talk referenced here, I believe was what I was remembering, but I could've sworn there was a line in there that explicitly talked about booting a Debian ARM - guess that was just something my brain cooked up. Wasn't out to mislead or anything.

Cheers

They showed Debian during WWDC at 1:40:00?

 

[casperes1996]

They showed Debian during WWDC at 1:40:00?

Hm - That might be what I got confused by, though I had it put in my head as being a booted system and that was clearly virtualisation - But I guess I just lost focus for a while and conflated things.

 

[dgdosen]

Hm - That might be what I got confused by, though I had it put in my head as being a booted system and that was clearly virtualisation - But I guess I just lost focus for a while and conflated things.

I wonder if they'll support virtualization on all macs...

 

[mr_roboto]

Explore the new system architecture of Apple silicon Macs - WWDC20 - Videos - Apple Developer

Discover how Macs with Apple silicon will deliver modern advantages using Apple's System-on-Chip (SoC) architecture. Leveraging a unified...

developer.apple.com

I want to point out that at 18:45 he starts describing reduced security mode and says this:

"Reduced security allows you to run any version of macOS, including the versions that are no longer signed by Apple."

It's not clear to me exactly what this means. In plain language it would imply that anything goes, but it might only mean that while it still does cryptographic verification, it politely disregards the fact that the signing key for an old version of macOS has expired. The fact that he immediately mentions it also permits notarized kernel extensions does suggest that a chain of trust is still active.

However, later on, there's a big clue that (much like current-day Recovery and Mac security options) there are more settings available when you use the command line rather than the GUI interface. At 19:07 he starts talking about csrutil and how you can use it to support "specific workflows". The ones he calls out are kernel extension dev, or if you are a researcher or hobbyist "exploring the Apple platform". He says csrutil provides "many knobs", and that some of them are highlighted here (meaning the bullet points in the slide). Said bullet points are:

• Secure Boot
• Root Volume Authentication
• System Integrity Protection

If you've got a knob to control secure boot, to me that implies you can turn it off. And "researcher exploring the Apple platform" implies enough access to actually research things, which means booting whatever you like. ("Researcher" often implies security researcher, i.e. someone who may want to instrument the kernel or other low level stuff.)

I'm trying to think about this from Apple's perspective, and my guess is that they don't want to publicly commit to supporting other operating systems on A-Si Macs. They're not a company which ships detailed hardware documentation or provides technical support for OS porting efforts. So, when they carefully craft their public messaging, they're trying not to say anything which could be interpreted as a promise of any of that.

This doesn't mean they have to fully lock down boot. Think about how it worked on Intel Macs - in recent years it's gotten harder to boot and run Linux on Macs, and the experience has degraded, but that's mainly been because Apple's system architecture began to depart from off-the-shelf PC hardware in several significant ways. They never flipped the switch and made T2 absolutely require an Apple-signed OS, although they certainly could have.

I suspect we're getting much the same here: there will be ways, you might have to use a command line tool to enable them, and you won't get support. The poor Linux experience will be even worse, and might never arrive since it's going to be tough for volunteer labor to reverse engineer all the peripherals in Apple Silicon and write drivers for all of it. But there's probably not going to be an artificial barrier.

(this is probably why they're emphasizing virtualization as the way to run Linux on an A-Si Mac - it does an end run around all that, makes it so that Linux need not know or care about the low level details of the hardware it's running on.)

 

[Mikael H]

I wonder if they'll support virtualization on all macs...

Why wouldn't they? Sounds like more work to explicitly exclude that option from some models.

 

[dgdosen]

Why wouldn't they? Sounds like more work to explicitly exclude that option from some models.

As a differentiator? Apple might not want to let professional developers get by with cheap ASi MB/MBAirs...

 

[leman]

As a differentiator? Apple might not want to let professional developers get by with cheap ASi MB/MBAirs...

Is there any precedent for this? Doesn’t really sound like something Apple would do...

 

[dogslobber]

Installing something VMWare ESXi for ARM when it's released would probably be the desired way. Even if Apple doesn't officially support it, the fact T2 security is now broken suggests a type 1 Hypervisor should be installable and then you should be able to boot ARM Mac OS X as a guest OS just like any other guest.

 

[Mikael H]

As a differentiator? Apple might not want to let professional developers get by with cheap ASi MB/MBAirs...

That would kind of be shooting themselves in the foot, though - that kind of arbitrary rules on "professional" use cases sound a lot more like Microsoft than like Apple.
Pretty much anything you can buy as a consumer today in the Intel and AMD worlds can run virtual machines. You can buy a $10 Raspberry Pi and run virtual machines if you're on a masochistic streak.

Limiting virtualization on lower-end Apple Silicon Macs would be akin to not letting MacBook Air users run Logic or Final Cut...

 

[throAU]

They don't support it officially:

Support and ability are two different things.

Apple will never support general linux on their hardware as they do not control the software, it's open source.

i.e., "if it works, go for it, but don't call us if it breaks"

 

[Yebubbleman]

Possible; just not probable. Apple has had about 3 years of the T2 era and has not dipped their toe into the "sign other people's OS images " business at all. If they were going to ramp up on that there probably would have been preparatory movements by now. (similar to moves of getting rid of 32-bit x86 when not going to support them at all on Apple Silicon Macs. etc. )

If Apple adds IOMMU , "pass through" to their hypervisor for GPU and networking there would be Microsoft and customized linux adjustments to the more directly exposed subsystems ( need apple specific drivers ) , but more than decent chance Apple isn't going to let those other OS images grab complete control of the system.

Apple Silicon Macs aren't going to be the only ARM based virtualization targets for ARM cod Linux/Windows OS images. Amazon AWS has a dramatically growing ARM OS hosting business ramping up. Microsoft's Azure is at earlier stages of growth but on the same bandwagon. All the large players are putting something into play.
All the OS implementors need to play nice with ARM virtualized environments so Apple isn't asking them to do anything extraordinarily difficult.

Also the current context isn't like it was in 2005-2006. Macs are not a 'small fish" jumping into a massively bigger pond of deeply entrench "whale" ( windows on x86 ). Linux and Windows are players on ARM. Linux more so as a proxy though Android, but straight Linux also. Apple already has a very major OS player on ARM ( iOS / iPad OS). It is a more of an even playing field race this time (more balkanizsed ). It is a much more strategically important to move their own stuff forward than to divert resources to helping the other options keep up on Mac hardware.

There are not massive hoards of windows on ARMs users out there who have to supply a "safety net" to because are nervous about optionally backing completely out of running macOS. On T2 Macs and going forward completely abandoning macOS on a Mac is not prudent. ( some of the basic boot security is hooked to running some variation of a macOS image.). that is only going to get into a deeper , more interwined relationship with the Apple Silicon Macs going forward.

Apple CAN allow other OSes to natively boot on Apple Silicon Macs. There isn't any kind of technological limitation being imposed by anyone other than themselves. Right now, you don't have an ARM64 desktop version of the most popular Linux distro out there (Ubuntu) and you don't have Microsoft making Windows 10 for ARM64 available to anyone that isn't an OEM. That's a pretty good reason to not open up Apple Silicon Macs to natively boot other OSes. That's not set in stone though. Intel Macs had been shipping for three months when Apple finally reversed course and put out the original Boot Camp.

I'm not saying it's definite or even likely. But we've been down this exact road before and hell DID freeze over then.

 

[casperes1996]

That would kind of be shooting themselves in the foot, though - that kind of arbitrary rules on "professional" use cases sound a lot more like Microsoft than like Apple.
Pretty much anything you can buy as a consumer today in the Intel and AMD worlds can run virtual machines. You can buy a $10 Raspberry Pi and run virtual machines if you're on a masochistic streak.

Limiting virtualization on lower-end Apple Silicon Macs would be akin to not letting MacBook Air users run Logic or Final Cut...

Agreed. It's not like there's a macOS Home Edition and a macOS Pro and Ultimate and Server (anymore...)
Though my first thought was Nvidia with some of the arbitrary driver limitations that are imposed on the GeForce line to push people to Titan or Quadro when the GeForce hardware is sometimes physically capable

 

[deconstruct60]

....

I'm not saying it's definite or even likely. But we've been down this exact road before and hell DID freeze over then.

This isn't exactly like 2005-2006 transition at all. Intel had a complete boot environments in their reference designs that supported EFI and BIOS. Apple adding something Intel already had working and that the standards committee around EFI was going to stuff into UEFI (major BIOS compatibility mode) was something that was going to happen whether Apple came to x86 or not. Adding BIOS in 2006-2007 was a "freebie" where the work was already 95+% done already for Apple and Apple wanted to leaverage a "safety net" feature for nervous switchers.

In 2020, Apple owns the stack. On "Apple designed silicon", the extremely dominate default boot environment is iBoot. That is something that is entirely Apple and there is no wide system vendor or OS implementer that targets it. Nobody else. So going from "about everybody is on it already" to "nobody else is on it at all" is extremely far from being 'exactly the same'. It is only "exactly the same" in a wishful thinking alternative reality.

Apple overtly says in the session that when boot in "Full Security" mode that the Mac gets all the same security that iPhones get. The notion that iBoot isn't here is ignoring that Apple is trying to unify the boot process here across the product line up. Mac's have more options so there will be some variation, but the default core objective is to be like the Apple Silicon devices.

On the 68K to PPC transition, did Apple add BIOS boot support to make it easier to boot Windows and other mainstream targeted OS instances ? No. Apple did not go out of their way to open up a broader set of OS. When Apple selected the 68K in the first place. Lots of boots support for other operating systems? No.

Furthermore, Apple's push to put instructions that nobody else has and function units that nobody else has into the CPU package is far more indicative to a path where the SoC is only good for being a Mac. More highly speciliazed CPUs for smaller sets of products; not a widening to a CPU product that is extremely broadly targeted. Apple has no interest at all of selling their CPUs to someone else to build systems with. That is 180 degrees opposite of Intel's position. ( yet another "one of these things is not like the other" characteristic of the current context. )

 

[deconstruct60]

I want to point out that at 18:45 he starts describing reduced security mode and says this:

"Reduced security allows you to run any version of macOS, including the versions that are no longer signed by Apple."

It's not clear to me exactly what this means. In plain language it would imply that anything goes, but it might only mean that while it still does cryptographic verification, it politely disregards the fact that the signing key for an old version of macOS has expired.

You are pretty much inventing ambiguity here. It does not say "versions that were never signed by Apple". That the OS images had to be have signed at one point in time is aboundantly clear there. The notion that no signature was required at all isn't no where in that statement. That is invention out of thin air.

This was signed means taking some cryptographic action. That it is an expired key and giving it a 'pass' anyway is another.

The fact that he immediately mentions it also permits notarized kernel extensions does suggest that a chain of trust is still active.

This is just misdirection. The requirement of a signature/notorized piece of code is yet another indication that crytographic examination of the code is not optional here either. Neither of these two paths skip signature or completely disregards the chain of trust. Loading notarized kernel extensions means the boot process as already started as extensions come in after the base kernel is present.

However, later on, there's a big clue that (much like current-day Recovery and Mac security options) there are more settings available when you use the command line rather than the GUI interface. At 19:07 he starts talking about csrutil and how you can use it to support "specific workflows". The ones he calls out are kernel extension dev, or if you are a researcher or hobbyist "exploring the Apple platform". He says csrutil provides "many knobs", and that some of them are highlighted here (meaning the bullet points in the slide). Said bullet points are:

• Secure Boot
• Root Volume Authentication
• System Integrity Protection

If you've got a knob to control secure boot, to me that implies you can turn it off.

Again there isn't much of a "However" here. Kernel extensions and loading stubs to debug/examine the kernel are all post boot handoff to macOS. The macOS is running.

That there are secure boot options is also clearly highlighted on the GUI interface. There are two options. There are not necessarily more than those two. csrutil is there to how system management and deployment tools do non GUI set-ups of a Mac ( so don't need to GUI operate everything.). Root Volume Authentication ( Reduced security mode. ) . SIP... again also something with a GUI interface.

The cherry picking of quotes from the transition hugely ignores that Apple also highlights that "Full Security" mode brings all the same security of the iPhone to the Mac. A very primary objective here is bring the Mac into alignment with the iPhone boot process security. If the user doesn't change anything that's what happens. Which probably means that path has no UEFI involved in it at all. That would be the "norm" that the macOS environment expects is one that is low level free of UEFI.

That is not the expectation that most other OS will expect on ARM.

Apple can allow researcher and explore just after macOS is booted and that still covers a huge fraction of what Mac users could do as before. Just because Apple enabled external drive booting and booting off of old OS images doesn't means they will have installed a switch to turn off every possible security mechanism of the boot process. Making all of it optional just inserts vectors to be exploited.


P.S. Also notice that the "system protections" , "extension loading" settings are per macOS instance now and not for the whole system. This is another indication that this is a post macOS boot process starting parameter. The down below macOS is extremely likely primarily set to whatever Apple wants to set it too. They are giving user options after macOS is activated.