7 ms·

Apple has kept the M1 Macs open for other operating systems, which is why a project like Asahi Linux can exist: https://asahilinux.org https://asahilinux.org A

Apple has kept the M1 Macs open for other operating systems, which is why a project like Asahi Linux can exist: https://asahilinux.org https://asahilinux.org Apple doesn't provide Linux drivers for their components, but neither does "anyone else", sadly. But it means that Linux on M1 Macs might actually happen in the near future. Edit: And Windows doesn't run natively/officially on M1 Macs because Microsoft has a stupid exclusivity deal: https://www.macrumors.com/2021/11/22/microsoft-qualcomm-arm-windows-exclusive-deal/ https://www.macrumors.com/2021/11/22/microsoft-qualcomm-arm-...

jeroenhd 5y ago
AMD and Intel provide drivers for their components. Realtek provides drivers for their components. Even Nvidia provides Linux drivers for their components, in proprietary form. Several laptop vendors even sell their hardware with Linux preinstalled. Apple not actively hindering Asahi Linux isn't exactly a great accomplishment. They chose not to write Linux drivers for their platform and that's their choice, but that puts them behind even Nvidia as far as supporting Linux goes.
- marcan_42 5y ago
  FWIW, Nvidia actively sabotaged the Nouveau project with the firmware signing story; Apple aren't doing that (their firmware is signed but loaded pre-boot and they provide OS images we can use to set all that up, so it's seamless for Linux).
  - bubblethink 5y ago
    Great progress on Asahi. What's the firmware situation like in general ? Since firmware won't be redistributable, would users need to periodically 'fetch' it from Apple CDNs or OS images ? Also, in the past broadcom has been quite problematic for wifi. How is it on the new macs ?
    - marcan_42 5y ago
      There's two classes of firmware: the bits loaded pre OS boot by the OS loader (which runs before our Linux loader), and the bits loaded by Linux. Both classes come from macOS recovery images and our installer takes care of fetching that from Apple's CDN. For the pre-boot firmware, it just gets installed into the Preboot partition the same way it does for macOS, and we don't have to worry about it after that. For the firmware loaded by Linux (current list: WiFi, video decoder), I have a design for a vendor firmware mechanism where the installer copies a tarball to the EFI boot partition, and then distros will have a script that extracts that on first boot or when it changes. Since Apple do not keep their firmware ABI stable across the board, we'll have specific firmware versions (=specific macOS versions they come from) "blessed" for Linux compatibility. For updates (bugfixes or security issues, chiefly) you'd re-run our installer which will eventually have an "upgrade my firmware please" mode. That would run from recovery mode, same as the original install. All this stuff is per-OS, so it does not affect any adjacent macOS install which will use its own firmware - you can upgrade macOS whenever you want without breaking Linux. Wifi works fine (modulo some firmware support details that'll get ironed out); people have been doing performance and stability tests and there is no major issue. I've heard stories about bad radio performance on Macs in the past, but those are almost certainly due to using the wrong firmware or config. That's what my patch set fixes: we use all the same firmwares and configs that Apple does, so we get the same results.
- bayindirh 5y ago
  > AMD and Intel provide drivers for their components. ATI/AMD intentionally redesigned their GPU silicon to make it's possible to develop open source drivers without exposing HDCP secrets, and even the open source drivers can use HDCP if they want to. This is not known very widely, but this is worthy of great praise if you ask me.
  - marcan_42 5y ago
    I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret. This is the case for Nvidia, for Apple M1s, etc; the OS never has to touch plaintext HDCP keys, and this has nothing to do with open source drivers. Can you clarify what you mean exactly? I have a hard time believing AMD ever ran HDCP keys through the Windows kernel.
    - bayindirh 5y ago
      > I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret. Yes, I'd not argue with that, I also never wanted or implied that I shall be able to get said keys from the card. AMD/ATI back in the day said that, they have intentionally coupled video decoders, related logic and HDCP to same IP block for performance and silicon real-estate reasons, but in order to keep their promises about open drivers and accessible hardware, starting with (then) next generation silicon, they'll move all HDCP stuff to another IP. In turn, they will allow unfettered access to all GPU including 3D and video related features sans HDCP. However, with that architecture, even open drivers can use HDCP related hardware and functions without compromising the security and licensing around it, as a result allowing identical experience and freedom (from a developer standpoint) regardless of the driver used. This is something to praise for, IMHO.
      - marcan_42 5y ago
        I still don't really understand how this is relevant for the drivers. Even if HDCP is part of another IP block, that doesn't mean open drivers can't use it. That's just an implementation detail. You can use HDCP on any platform the same way the proprietary drivers would (if you implement the right knobs to control it). Do you have a reference with more detail? Ultimately the open driver should always be able to do all the same things the closed driver does and get the same result. If there are any secrets in the closed driver that "can't" be exposed, that's a security flaw in the design.
- gurkendoktor 5y ago
  I'd agree if we were talking about desktop machines, which are basically a box around a GPU, CPU, and some networking. The situation there is infinitely better than on the M1 Mac Mini. But if I go and buy a random Windows _laptop_ and try to slap Linux on it, I might have all sorts of issues with the trackpad, webcam, fingerprint sensors, never mind sleep/wake. That's why Linux laptop vendors are a thing and deserve our praise (just like the companies you've mentioned)! All I'm saying is that Apple is hardly the only company left that doesn't actively support Linux.
- roywashere 5y ago
  But it is not all about GPUs. Broadcom is notoriously bad on many items and is used a lot for wifi and BLE and webcams, as is that touch pad vendor whose name I forgot that is in many laptops. I installed Linux on a 2015 MBP recently and there is no real way to get the webcam working.
phh 5y ago
> Apple doesn't provide Linux drivers for their components, but neither does "anyone else", sadly. ?!?! There are vendor-provided Linux drivers for pretty much everything? Everything in Intel and AMD CPUs are supported in mainline. nVidia provides Linux drivers. I don't have a clear view about how many devices nowadays are reverse-engineered, and how many are provided by someone with datasheet (it happens quite often that mainline drivers are not provided by vendor directly, but by a third party that got access to datasheet), but it really feels like most vendors do work with OS vendors to get their hardware supported, and that Apple is totally an exception in the hardware world.
- bayindirh 5y ago
  Apple has requested and obtained semi-custom hardware from vendors before. Their Boradcom wireless cards (around 2006-2012 IIRC) are almost produced only for them, and getting it run on Linux was a long endeavor. Also, like Java, they have maintained their own nVidia drivers up to a certain point. Today that gap is smaller since HW manufacturers are more open about their firmwares and drivers, and Linux is more widely adopted.
  - marcan_42 5y ago
    > Apple has requested and obtained semi-custom hardware from vendors before. Their Boradcom wireless cards (around 2006-2012 IIRC) are almost produced only for them, and getting it run on Linux was a long endeavor. I just sent in a patch series to Linux a few days ago to get all custom Broadcom cards for T2 and M1 Macs working (~2017-present), with the right firmware selection logic. Took a week or so to develop and test on both ARM64 and x86. (There was some prior art but certainly nothing that would've taken more than a few more weeks to work out from scratch; besides, I found a Broadcom source dump for Android that contained most of the interesting knowledge excluding the Apple-only bits, since some of it is relevant to newer non-Apple chips too). Once you have a team of the right people and enough motivation, getting reverse engineered hardware working on Linux doesn't take as long as everyone thinks :-)
    - bayindirh 5y ago
washadjeffmad 5y ago
People unfamiliar with computer history beyond the past decade are downvoting you. Apple may not contribute much more than a bare platform with M1, but that isn't unusual in the scope of computer history. What's important is that they are not actively enforcing exclusivity or deterring the attempt. They've even shown tacit support in recent EFI patches by making changes that preserve the current mechanism other OSes can be loaded.

jeroenhd 5y ago

AMD and Intel provide drivers for their components. Realtek provides drivers for their components. Even Nvidia provides Linux drivers for their components, in proprietary form. Several laptop vendors even sell their hardware with Linux preinstalled. Apple not actively hindering Asahi Linux isn't exactly a great accomplishment. They chose not to write Linux drivers for their platform and that's their choice, but that puts them behind even Nvidia as far as supporting Linux goes.

marcan_42 5y ago
FWIW, Nvidia actively sabotaged the Nouveau project with the firmware signing story; Apple aren't doing that (their firmware is signed but loaded pre-boot and they provide OS images we can use to set all that up, so it's seamless for Linux).
- bubblethink 5y ago
  Great progress on Asahi. What's the firmware situation like in general ? Since firmware won't be redistributable, would users need to periodically 'fetch' it from Apple CDNs or OS images ? Also, in the past broadcom has been quite problematic for wifi. How is it on the new macs ?
  - marcan_42 5y ago
    There's two classes of firmware: the bits loaded pre OS boot by the OS loader (which runs before our Linux loader), and the bits loaded by Linux. Both classes come from macOS recovery images and our installer takes care of fetching that from Apple's CDN. For the pre-boot firmware, it just gets installed into the Preboot partition the same way it does for macOS, and we don't have to worry about it after that. For the firmware loaded by Linux (current list: WiFi, video decoder), I have a design for a vendor firmware mechanism where the installer copies a tarball to the EFI boot partition, and then distros will have a script that extracts that on first boot or when it changes. Since Apple do not keep their firmware ABI stable across the board, we'll have specific firmware versions (=specific macOS versions they come from) "blessed" for Linux compatibility. For updates (bugfixes or security issues, chiefly) you'd re-run our installer which will eventually have an "upgrade my firmware please" mode. That would run from recovery mode, same as the original install. All this stuff is per-OS, so it does not affect any adjacent macOS install which will use its own firmware - you can upgrade macOS whenever you want without breaking Linux. Wifi works fine (modulo some firmware support details that'll get ironed out); people have been doing performance and stability tests and there is no major issue. I've heard stories about bad radio performance on Macs in the past, but those are almost certainly due to using the wrong firmware or config. That's what my patch set fixes: we use all the same firmwares and configs that Apple does, so we get the same results.
bayindirh 5y ago
> AMD and Intel provide drivers for their components. ATI/AMD intentionally redesigned their GPU silicon to make it's possible to develop open source drivers without exposing HDCP secrets, and even the open source drivers can use HDCP if they want to. This is not known very widely, but this is worthy of great praise if you ask me.
- marcan_42 5y ago
  I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret. This is the case for Nvidia, for Apple M1s, etc; the OS never has to touch plaintext HDCP keys, and this has nothing to do with open source drivers. Can you clarify what you mean exactly? I have a hard time believing AMD ever ran HDCP keys through the Windows kernel.
  - bayindirh 5y ago
    > I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret. Yes, I'd not argue with that, I also never wanted or implied that I shall be able to get said keys from the card. AMD/ATI back in the day said that, they have intentionally coupled video decoders, related logic and HDCP to same IP block for performance and silicon real-estate reasons, but in order to keep their promises about open drivers and accessible hardware, starting with (then) next generation silicon, they'll move all HDCP stuff to another IP. In turn, they will allow unfettered access to all GPU including 3D and video related features sans HDCP. However, with that architecture, even open drivers can use HDCP related hardware and functions without compromising the security and licensing around it, as a result allowing identical experience and freedom (from a developer standpoint) regardless of the driver used. This is something to praise for, IMHO.
    - marcan_42 5y ago
      I still don't really understand how this is relevant for the drivers. Even if HDCP is part of another IP block, that doesn't mean open drivers can't use it. That's just an implementation detail. You can use HDCP on any platform the same way the proprietary drivers would (if you implement the right knobs to control it). Do you have a reference with more detail? Ultimately the open driver should always be able to do all the same things the closed driver does and get the same result. If there are any secrets in the closed driver that "can't" be exposed, that's a security flaw in the design.
gurkendoktor 5y ago
I'd agree if we were talking about desktop machines, which are basically a box around a GPU, CPU, and some networking. The situation there is infinitely better than on the M1 Mac Mini. But if I go and buy a random Windows _laptop_ and try to slap Linux on it, I might have all sorts of issues with the trackpad, webcam, fingerprint sensors, never mind sleep/wake. That's why Linux laptop vendors are a thing and deserve our praise (just like the companies you've mentioned)! All I'm saying is that Apple is hardly the only company left that doesn't actively support Linux.
roywashere 5y ago
But it is not all about GPUs. Broadcom is notoriously bad on many items and is used a lot for wifi and BLE and webcams, as is that touch pad vendor whose name I forgot that is in many laptops. I installed Linux on a 2015 MBP recently and there is no real way to get the webcam working.

phh 5y ago

> Apple doesn't provide Linux drivers for their components, but neither does "anyone else", sadly. ?!?! There are vendor-provided Linux drivers for pretty much everything? Everything in Intel and AMD CPUs are supported in mainline. nVidia provides Linux drivers. I don't have a clear view about how many devices nowadays are reverse-engineered, and how many are provided by someone with datasheet (it happens quite often that mainline drivers are not provided by vendor directly, but by a third party that got access to datasheet), but it really feels like most vendors do work with OS vendors to get their hardware supported, and that Apple is totally an exception in the hardware world.

bayindirh 5y ago
Apple has requested and obtained semi-custom hardware from vendors before. Their Boradcom wireless cards (around 2006-2012 IIRC) are almost produced only for them, and getting it run on Linux was a long endeavor. Also, like Java, they have maintained their own nVidia drivers up to a certain point. Today that gap is smaller since HW manufacturers are more open about their firmwares and drivers, and Linux is more widely adopted.
- marcan_42 5y ago
  > Apple has requested and obtained semi-custom hardware from vendors before. Their Boradcom wireless cards (around 2006-2012 IIRC) are almost produced only for them, and getting it run on Linux was a long endeavor. I just sent in a patch series to Linux a few days ago to get all custom Broadcom cards for T2 and M1 Macs working (~2017-present), with the right firmware selection logic. Took a week or so to develop and test on both ARM64 and x86. (There was some prior art but certainly nothing that would've taken more than a few more weeks to work out from scratch; besides, I found a Broadcom source dump for Android that contained most of the interesting knowledge excluding the Apple-only bits, since some of it is relevant to newer non-Apple chips too). Once you have a team of the right people and enough motivation, getting reverse engineered hardware working on Linux doesn't take as long as everyone thinks :-)
  - bayindirh 5y ago

washadjeffmad 5y ago

People unfamiliar with computer history beyond the past decade are downvoting you. Apple may not contribute much more than a bare platform with M1, but that isn't unusual in the scope of computer history. What's important is that they are not actively enforcing exclusivity or deterring the attempt. They've even shown tacit support in recent EFI patches by making changes that preserve the current mechanism other OSes can be loaded.