4 ms·

I agree that this is mostly a small number of engineers (with approval) being helpful. This has almost no bearing on Apple profit. The number of people who wa

I agree that this is mostly a small number of engineers (with approval) being helpful. This has almost no bearing on Apple profit. The number of people who want to run Linux on an Apple Mac is very small compared to their other markets. The only tangible benefit to the company is that this may add a bit of goodwill and slightly reduce the volume of the vocal detractors. As others have pointed out, it may also help if they are moving to add back bootcamp support for Windows (on ARM). Apple has added better support for virtualization at the OS level in recent years and that handles the needs of most devs.

GeekyBear 5y ago
> I agree that this is mostly a small number of engineers (with approval) being helpful. The M1 Macs have their security settings applied per partition instead of per computer. If you set the bootloader to "permissive security policy", you can boot from a Linux partition without effecting the security of the system when you boot from the MacOS partition. This is a big change over the way things have previously worked on iOS (where there is no option to unlock the bootloader) or the Mac. It probably wasn't a quick hack that a couple of guys stuck in when nobody was looking.
- gsnedders 5y ago
  Note there's also macOS-related reasons to use the different modes: Reduced security mode is needed to boot into outdated macOS installs (specifically, I believe this is "outdated, insecure, at install-time"), along with loading kernel extensions (which aren't supported in full security mode on Apple Silicon). Permissive security mode is needed to boot into macOS with a custom XNU kernel. But yes, this is a significant change to iOS devices, but not to older macOS devices.
  - GeekyBear 5y ago
    > But yes, this is a significant change to iOS devices, but not to older macOS devices. Previously the Macs had their security settings applied per computer, not per partition.
- pbronez 5y ago
  Oh cool, I wasn't aware of that. I like that option a lot. It's nice to have access to both a walled garden and an open one.
- sharikous 5y ago
  The fact that you can boot the M1 from a different OS (but you still need the internal SSD even if you boot from an external disk) is a corporate decision. The fact that someone decided to provide support for a raw image instead of a Mach-O file could very well be the work of someone ar a much lower level.
  - larkost 5y ago
    I disagree with your assertion that the requirement for the internal SSD was a marketing decision (your word was "corporate", but that could mean anything). I think that it was probably a technical decision. Likely there is a very small bit of bootstrap code stuffed into a ROM somewhere, and the only thing that bootstrap code enables it to read from some protected part of the onboard SSD, which then gives you the next round of bootstrap enabling you to read from other devices (e.g. all the code needed to power up and use the hardware needed to get to an external drive, and the code to read the partitions on said drive). Someone made the decision that it would be better to use the bit of internal SSD (since it would "always" be there), that could be changed later, rather than hard-code this into comparatively expensive silicon. Unless your internal drive goes bad, it is a pretty good compromise. I seriously doubt that anyone in marketing cared about this.
    - marcan_42 5y ago
      Support for external disks massively increases the attack surface of the security-sensitive iBoot bootloader, and anything messing with USB (nevermind Thunderbolt) is almost guaranteed to have exploitable attack surface. This was absolutely a technical decision. iBoot is a lot simpler not supporting external storage. The SecureROM boots iBoot1 from NOR flash, then that has the SSD driver code. It would certainly be possible to add support for external storage, as long as it still fits in NOR. But I doubt they will.
    - mehrdada 5y ago
      (not the GP) I think you are attacking the strawman here, as your own post admits, by interpreting "corporate" as exclusively "marketing" and not including technical folks in it. I agree with you the decision is also partially driven by technical folks at the company, but given macOS on ARM is really closer to iOS, the natural course of action would have been to simply clone the iOS model of secure boot, not to rethink it. That observation alone almost certainly implies it has been given explicit thought at relatively senior levels of the engineering hierarchy, at the very least. My take is the company deliberated about this trade-off quite explicitly at some length and decided the Mac serves the world in its current capacity as a "computer" (i.e. the truck in the truck vs car analogy) and that they do not wish to limit the capabilities of the existing Mac that people love in any shape or form by moving to ARM, which was highly speculated and ripe for potential backlash. They probably decided the Mac would be an "open" system to some degree (at least as open as it already was) and iOS would be the closed mass market computing device optimizing for security and dependable end-to-end experience.
- saagarjha 5y ago
  > It probably wasn't a quick hack that a couple of guys stuck in when nobody was looking. I mean, that's not what the parent comment said: > I agree that this is mostly a small number of engineers (with approval) being helpful. Here's some more details from someone who actually worked on this: https://twitter.com/XenoKovah/status/1339914714055368704 https://twitter.com/XenoKovah/status/1339914714055368704
dasil003 5y ago
I don't disagree with what you're saying, but focusing on the number of people that want to run Linux on a Mac and the tangible short-term benefits misses the larger dynamics that could play out over time. The bigger opportunity is expanding the footprint and flexibility of Apple Silicon in general. As a developer the new MacBook Pros performance characteristics were too juicy to ignore, the main pain points are virtualization and architecture shift. I'm not knowledgeable enough about the low level details to have a fully formed idea of impact of these pain points yet—maybe Apple Silicon and ARM support are equivalent in practice when it comes to development/deployment—but it certainly makes me feel more comfortable paying the Apple premium the more diverse and open the supported use cases are.
- mekster 5y ago
  Maybe they want to ship Apple Silicon to server vendors?

GeekyBear 5y ago

> I agree that this is mostly a small number of engineers (with approval) being helpful. The M1 Macs have their security settings applied per partition instead of per computer. If you set the bootloader to "permissive security policy", you can boot from a Linux partition without effecting the security of the system when you boot from the MacOS partition. This is a big change over the way things have previously worked on iOS (where there is no option to unlock the bootloader) or the Mac. It probably wasn't a quick hack that a couple of guys stuck in when nobody was looking.

gsnedders 5y ago
Note there's also macOS-related reasons to use the different modes: Reduced security mode is needed to boot into outdated macOS installs (specifically, I believe this is "outdated, insecure, at install-time"), along with loading kernel extensions (which aren't supported in full security mode on Apple Silicon). Permissive security mode is needed to boot into macOS with a custom XNU kernel. But yes, this is a significant change to iOS devices, but not to older macOS devices.
- GeekyBear 5y ago
  > But yes, this is a significant change to iOS devices, but not to older macOS devices. Previously the Macs had their security settings applied per computer, not per partition.
pbronez 5y ago
Oh cool, I wasn't aware of that. I like that option a lot. It's nice to have access to both a walled garden and an open one.
sharikous 5y ago
The fact that you can boot the M1 from a different OS (but you still need the internal SSD even if you boot from an external disk) is a corporate decision. The fact that someone decided to provide support for a raw image instead of a Mach-O file could very well be the work of someone ar a much lower level.
- larkost 5y ago
  I disagree with your assertion that the requirement for the internal SSD was a marketing decision (your word was "corporate", but that could mean anything). I think that it was probably a technical decision. Likely there is a very small bit of bootstrap code stuffed into a ROM somewhere, and the only thing that bootstrap code enables it to read from some protected part of the onboard SSD, which then gives you the next round of bootstrap enabling you to read from other devices (e.g. all the code needed to power up and use the hardware needed to get to an external drive, and the code to read the partitions on said drive). Someone made the decision that it would be better to use the bit of internal SSD (since it would "always" be there), that could be changed later, rather than hard-code this into comparatively expensive silicon. Unless your internal drive goes bad, it is a pretty good compromise. I seriously doubt that anyone in marketing cared about this.
  - marcan_42 5y ago
    Support for external disks massively increases the attack surface of the security-sensitive iBoot bootloader, and anything messing with USB (nevermind Thunderbolt) is almost guaranteed to have exploitable attack surface. This was absolutely a technical decision. iBoot is a lot simpler not supporting external storage. The SecureROM boots iBoot1 from NOR flash, then that has the SSD driver code. It would certainly be possible to add support for external storage, as long as it still fits in NOR. But I doubt they will.
  - mehrdada 5y ago
    (not the GP) I think you are attacking the strawman here, as your own post admits, by interpreting "corporate" as exclusively "marketing" and not including technical folks in it. I agree with you the decision is also partially driven by technical folks at the company, but given macOS on ARM is really closer to iOS, the natural course of action would have been to simply clone the iOS model of secure boot, not to rethink it. That observation alone almost certainly implies it has been given explicit thought at relatively senior levels of the engineering hierarchy, at the very least. My take is the company deliberated about this trade-off quite explicitly at some length and decided the Mac serves the world in its current capacity as a "computer" (i.e. the truck in the truck vs car analogy) and that they do not wish to limit the capabilities of the existing Mac that people love in any shape or form by moving to ARM, which was highly speculated and ripe for potential backlash. They probably decided the Mac would be an "open" system to some degree (at least as open as it already was) and iOS would be the closed mass market computing device optimizing for security and dependable end-to-end experience.
saagarjha 5y ago
> It probably wasn't a quick hack that a couple of guys stuck in when nobody was looking. I mean, that's not what the parent comment said: > I agree that this is mostly a small number of engineers (with approval) being helpful. Here's some more details from someone who actually worked on this: https://twitter.com/XenoKovah/status/1339914714055368704 https://twitter.com/XenoKovah/status/1339914714055368704

dasil003 5y ago

I don't disagree with what you're saying, but focusing on the number of people that want to run Linux on a Mac and the tangible short-term benefits misses the larger dynamics that could play out over time. The bigger opportunity is expanding the footprint and flexibility of Apple Silicon in general. As a developer the new MacBook Pros performance characteristics were too juicy to ignore, the main pain points are virtualization and architecture shift. I'm not knowledgeable enough about the low level details to have a fully formed idea of impact of these pain points yet—maybe Apple Silicon and ARM support are equivalent in practice when it comes to development/deployment—but it certainly makes me feel more comfortable paying the Apple premium the more diverse and open the supported use cases are.

mekster 5y ago
Maybe they want to ship Apple Silicon to server vendors?