5 ms·

This is absolutely the right thing to do and it's quite assuring to see they put out a clear cut support article for this so quick. However without the specifi

This is absolutely the right thing to do and it's quite assuring to see they put out a clear cut support article for this so quick. However without the specifications for the security chip, GPU, SoC - running an alternative OS on the M1 Macs is very much a no-go. Apple could work closely with Microsoft to get Windows/ARM working on their ARM implementation but I am sure that's way more work than was Bootcamp. (Apple proprietary firmware is a big question and so are the various drivers obviously). This is why ARM is a mess that isn't worth dealing with even with better performance per watt. What would be really great is if Apple did what Dell does - Make a downloadable Ubuntu ISO with drivers and firmware integration available that works as a fully functional alternative OS. Or make the h/w specs available so people can do the work themselves. I am well aware none of it will actually happen but nonetheless it would get more people to buy into what seems to be an excellent hardware platform.

rektide 6y ago
This system seems to only have an "Apple secure mode" of sorts, & a gradient of less secure modes. In contrast, in the regular PC ecosystem, there's what seems like a reasonably effective user-empowering situation, SO FAR, where computers have been coming with UEFI Secure Boot[1] for over half a decade. I don't fully understand what is required to generate secure boot images & possible foibles or potential confounding factors, but it's seemed like the base requirements[2] include the system advertising it's core "platform key" & allowing users to create their own securing keys based off this, to upload those keys, & there-by allow user-signed images to boot, securely. One of the best guides to this all is the NSA's[3]. The contrast is that Apple seemingly let's one disarm the boot security system, where-as Secure Boot, so far, has allowed users to put the security system to work as they please. Worth mentioning Chromebooks. I'm even less familiar with the particulars of their boot system, but they most-often have a "developer mode"[4], which disarms the OS protection mechanisms allowing one to install whatever onto the system. Fun fact, on Chromebox systems, this either is or was often achieved by opening the case & removing a specific screw. Once developer mode is enabled, the system will at boot-up show an image notifying the user that the system is insecure, & will boot unsigned code & allow modification to the drive. And worth mentioning Android! You the user almost never have power over your system. Once your device is no longer maintained, throw it away, because there's nothing you can do to it & in an unmaintained state it is almost certainly insecure. Maybe some intrepid hackers will have found some exploit to bypass the protection mechanisms, and maybe, maybe, you bought one of the probably <1% of devices that still has an unlocked bootloader, and in these exceptional cases you can probably get your own well maintained OS like LineageOS on your device, but for most people, you have no control & can do nothing to your device that is not approved, and the security system is very much designed to keep you out of your own device. > However without the specifications for the security chip, GPU, SoC - running anything on it is practically meaningless I'm having similar thoughts about Microsoft's recent announcement, that they have partnered with Intel, AMD, and Qualcomm to get their custom Pluton security chip[5] embedded in seemingly most major cpus going forward. Where-as Google begot an "open source root of trust" system based around the open hardware RISC-V chip[6]- something that can be inspected, checked out, & deployed in new designs gratis- Microsoft seems to be relying on a high degree of trust in their systems & engineering & how that will ultimately empower and/or exclude the user. This new silicon we expect almost literally everywhere comes at a time when Microsoft is about to make a critical requirement of many of the Secure Boot technologies that have been building[7], with a January 1st deadline for Secure Boot support. Also worth pointing out some of the secure-boot related "whoopsies" that have happened[8][9], recently, & further back. Overall, all this flurry of activity around securing that's happened so quickly has made me prsonally a little nervous, a bit on edge. Thusfar UEFI Secure Boot has seemed to continue to give the user respect, power over their system, & been quite ahead of the pack in doing so. But it's intimidating how much we are taking on faith, hoping that we continue to retain access. The glossy media-blitz PR of Pluton was ultra-light on technical details; that was intimidating. I want to believe the PC platform continues to be a place for open innovation & where users have the power to maintain their systems & keep control over them, if they want to do so, and in all likelihood Secure Boot and whatever Pluton ends up being probably will continue to help us in that. But it always feels like the keys could be snatched away, that someone could make some decision, & PCs could close off, like so vary many other platforms. Notably also, to my understanding, UEFI Secure Boot does not require users to be able to remove the systems signing keys, so Microsoft & the manufacturer will retain access to the boot layer of your system no matter what. (I'm not sure about this.) [1] https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_In... [2] https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot https://docs.microsoft.com/en-us/windows-hardware/design/dev... [3] https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-Secure-Boot-Customization-UOO168873-20.PDF https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR... [4] https://chromium.googlesource.com/chromiumos/docs/+/master/developer_mode.md https://chromium.googlesource.com/chromiumos/docs/+/master/d... [5] https://www.microsoft.com/security/blog/2020/11/17/meet-the-microsoft-pluton-processor-the-security-chip-designed-for-the-future-of-windows-pcs/ https://www.microsoft.com/security/blog/2020/11/17/meet-the-... [6] https://techcrunch.com/2019/11/05/google-opentitan-secure-chip/ https://techcrunch.com/2019/11/05/google-opentitan-secure-ch... [7] https://redmondmag.com/articles/2020/06/11/windows-server-hardware-security-requirements.aspx https://redmondmag.com/articles/2020/06/11/windows-server-ha... [8] https://www.computerworld.com/article/3528302/the-mess-behind-microsoft-s-yanked-uefi-patch-kb-4524244.html https://www.computerworld.com/article/3528302/the-mess-behin... [9] https://www.zdnet.com/article/microsoft-secure-boot-key-debacle-causes-security-panic/ https://www.zdnet.com/article/microsoft-secure-boot-key-deba...
- blinkingled 6y ago
  I completely agree with you on UEFI - PC vendors mostly have really done the right thing vis-a-vis Secure Booting Windows with MS keys and Linux with custom MOKs. Keep in mind anything Intel does with their CPUs and GPUs has historically been Linux compatible for the most part - that's just the way the market has been. So it is not far fetched to assume whatever MS is doing with Pluton would at the very least not prevent Linux or BSDs from booting on x86 hardware. And with the Microsoft of today they might even release the specs - after all there is talk about Pluton being used in Azure - and Linux/BSDs can benefit from it too.
webmobdev 6y ago
Yes, without drivers for the SoC and other Apple hardwares, we may only have hackintosh kind of OSes on these ARM Mac. Moreover, you have to cripple your own macOS to run others OS, which seems a deliberate design to discourage users: > Permissive Security: Does not enforce any requirements on the bootable operating system. Note: The Permissive Security option appears only when System Integrity Protection (SIP) is disabled. To disable SIP, start up your Mac in macOS Recovery, open Terminal, then run the command csrutil disable.
- josephcsible 6y ago
  Disabling SIP doesn't cripple macOS.
  - arcticbull 6y ago
    It simply affords you the same level of security enjoyed on macOS up to and including 10.10 (Yosemite) -- which was state of the art until July 9, 2018.
    - josephcsible 6y ago
      Are Windows and Linux insecure? They don't have anything like SIP. Also, the whole idea of SIP has a strong https://xkcd.com/1200/ https://xkcd.com/1200/ vibe.
      - warkdarrior 6y ago
        Windows has Windows Resource Protection (previously known as Windows File Protection) with same goals as SIP. SELinux for Linux can achieve similar levels of protection.
        Wowfunhappy 6y ago
        Windows Resource Protection doesn't prevent code injection, and can be disabled from within the OS. I don't consider them equivalent.
1996 6y ago
An M1 MBA running Windows 10/ARM? I'd buy that right now!
- sys_64738 6y ago
  Who would write the Windows drivers for the M1 SoC?
  - blinkingled 6y ago
    That would have to be Apple just like Bootcamp. It's not just drivers - there's also bootloader and firmware.
    - threeseed 6y ago
      Bootcamp very much belonged to a different era where having access to Windows apps was important in particular in the enterprise space. These days everything has moved to mobile and web apps that I can't imagine they will bother investing the substantial effort to port the drivers across. Especially since Microsoft doesn't seem to take Windows RT all that seriously.
    - Wowfunhappy 6y ago
      People hacked Windows onto early Intel Macs before Apple made it official with Bootcamp!
      - wolrah 6y ago
        > People hacked Windows onto early Intel Macs before Apple made it official with Bootcamp! Slightly different there though, considering that the early Intel Macs were more or less identical to contemporary PC laptops internally other than the lack of BIOS compatibility mode. Drivers would be much more challenging in this case.
    - skissane 6y ago
      Microsoft should offer to fund the driver development – either develop the drivers themselves, or pay Apple to do it (this assumes that Apple would be willing to cooperate with either option.) Getting Windows ARM to work on Apple hardware would do a lot to build mindshare on Windows ARM and contribute to the success of Windows on the ARM platform. Microsoft needs this much more than Apple does.
ogre_codes 6y ago
> Make a downloadable Ubuntu ISO with drivers and firmware integration available that works as a fully functional alternative OS If Apple were to do it, it would make a lot more sense to release a version of Darwin with all the drivers.
alwillis 6y ago
I am well aware none of it will actually happen but nonetheless it would get more people to buy into what seems to be an excellent hardware platform. Apple had a record Mac quarter (July-September), generating a little over $9 billion in revenue; Mac sales were up 37% from the year before. A lot of this was due to people buying Macs to WFH during the pandemic. But it also shows they don't have to change what they've been doing to keep sales going. I suspect when Docker gets running on M1 Macs, a lot of the need to boot into Linux will dissipate. Same thing when Linux running in a VM on Apple Silicon Macs is much faster than any comparable PC hardware you can buy. Remember, they demoed Debian running in a VM on a prototype M1 Mac nearly 6 months ago, so we know it's coming. And while I get it—I used to help support a lab of triple-boot Macs (MacOS/Linux/Windows)—being able to boot 3rd party operating systems on manufacturers machines is going to become less common. With the goal is to diminish the attack surface for the bad guys, my hope is Apple's hypervisor technology will enable access to enough things to create a fast, workable VM solution for 3rd-party operating systems on M1 Macs without sacrificing security.

rektide 6y ago

This system seems to only have an "Apple secure mode" of sorts, & a gradient of less secure modes. In contrast, in the regular PC ecosystem, there's what seems like a reasonably effective user-empowering situation, SO FAR, where computers have been coming with UEFI Secure Boot[1] for over half a decade. I don't fully understand what is required to generate secure boot images & possible foibles or potential confounding factors, but it's seemed like the base requirements[2] include the system advertising it's core "platform key" & allowing users to create their own securing keys based off this, to upload those keys, & there-by allow user-signed images to boot, securely. One of the best guides to this all is the NSA's[3]. The contrast is that Apple seemingly let's one disarm the boot security system, where-as Secure Boot, so far, has allowed users to put the security system to work as they please. Worth mentioning Chromebooks. I'm even less familiar with the particulars of their boot system, but they most-often have a "developer mode"[4], which disarms the OS protection mechanisms allowing one to install whatever onto the system. Fun fact, on Chromebox systems, this either is or was often achieved by opening the case & removing a specific screw. Once developer mode is enabled, the system will at boot-up show an image notifying the user that the system is insecure, & will boot unsigned code & allow modification to the drive. And worth mentioning Android! You the user almost never have power over your system. Once your device is no longer maintained, throw it away, because there's nothing you can do to it & in an unmaintained state it is almost certainly insecure. Maybe some intrepid hackers will have found some exploit to bypass the protection mechanisms, and maybe, maybe, you bought one of the probably <1% of devices that still has an unlocked bootloader, and in these exceptional cases you can probably get your own well maintained OS like LineageOS on your device, but for most people, you have no control & can do nothing to your device that is not approved, and the security system is very much designed to keep you out of your own device. > However without the specifications for the security chip, GPU, SoC - running anything on it is practically meaningless I'm having similar thoughts about Microsoft's recent announcement, that they have partnered with Intel, AMD, and Qualcomm to get their custom Pluton security chip[5] embedded in seemingly most major cpus going forward. Where-as Google begot an "open source root of trust" system based around the open hardware RISC-V chip[6]- something that can be inspected, checked out, & deployed in new designs gratis- Microsoft seems to be relying on a high degree of trust in their systems & engineering & how that will ultimately empower and/or exclude the user. This new silicon we expect almost literally everywhere comes at a time when Microsoft is about to make a critical requirement of many of the Secure Boot technologies that have been building[7], with a January 1st deadline for Secure Boot support. Also worth pointing out some of the secure-boot related "whoopsies" that have happened[8][9], recently, & further back. Overall, all this flurry of activity around securing that's happened so quickly has made me prsonally a little nervous, a bit on edge. Thusfar UEFI Secure Boot has seemed to continue to give the user respect, power over their system, & been quite ahead of the pack in doing so. But it's intimidating how much we are taking on faith, hoping that we continue to retain access. The glossy media-blitz PR of Pluton was ultra-light on technical details; that was intimidating. I want to believe the PC platform continues to be a place for open innovation & where users have the power to maintain their systems & keep control over them, if they want to do so, and in all likelihood Secure Boot and whatever Pluton ends up being probably will continue to help us in that. But it always feels like the keys could be snatched away, that someone could make some decision, & PCs could close off, like so vary many other platforms. Notably also, to my understanding, UEFI Secure Boot does not require users to be able to remove the systems signing keys, so Microsoft & the manufacturer will retain access to the boot layer of your system no matter what. (I'm not sure about this.) [1] https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_In... [2] https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot https://docs.microsoft.com/en-us/windows-hardware/design/dev... [3] https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-Secure-Boot-Customization-UOO168873-20.PDF https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR... [4] https://chromium.googlesource.com/chromiumos/docs/+/master/developer_mode.md https://chromium.googlesource.com/chromiumos/docs/+/master/d... [5] https://www.microsoft.com/security/blog/2020/11/17/meet-the-microsoft-pluton-processor-the-security-chip-designed-for-the-future-of-windows-pcs/ https://www.microsoft.com/security/blog/2020/11/17/meet-the-... [6] https://techcrunch.com/2019/11/05/google-opentitan-secure-chip/ https://techcrunch.com/2019/11/05/google-opentitan-secure-ch... [7] https://redmondmag.com/articles/2020/06/11/windows-server-hardware-security-requirements.aspx https://redmondmag.com/articles/2020/06/11/windows-server-ha... [8] https://www.computerworld.com/article/3528302/the-mess-behind-microsoft-s-yanked-uefi-patch-kb-4524244.html https://www.computerworld.com/article/3528302/the-mess-behin... [9] https://www.zdnet.com/article/microsoft-secure-boot-key-debacle-causes-security-panic/ https://www.zdnet.com/article/microsoft-secure-boot-key-deba...

blinkingled 6y ago
I completely agree with you on UEFI - PC vendors mostly have really done the right thing vis-a-vis Secure Booting Windows with MS keys and Linux with custom MOKs. Keep in mind anything Intel does with their CPUs and GPUs has historically been Linux compatible for the most part - that's just the way the market has been. So it is not far fetched to assume whatever MS is doing with Pluton would at the very least not prevent Linux or BSDs from booting on x86 hardware. And with the Microsoft of today they might even release the specs - after all there is talk about Pluton being used in Azure - and Linux/BSDs can benefit from it too.

webmobdev 6y ago

Yes, without drivers for the SoC and other Apple hardwares, we may only have hackintosh kind of OSes on these ARM Mac. Moreover, you have to cripple your own macOS to run others OS, which seems a deliberate design to discourage users: > Permissive Security: Does not enforce any requirements on the bootable operating system. Note: The Permissive Security option appears only when System Integrity Protection (SIP) is disabled. To disable SIP, start up your Mac in macOS Recovery, open Terminal, then run the command csrutil disable.

josephcsible 6y ago
Disabling SIP doesn't cripple macOS.
- arcticbull 6y ago
  It simply affords you the same level of security enjoyed on macOS up to and including 10.10 (Yosemite) -- which was state of the art until July 9, 2018.
  - josephcsible 6y ago
    Are Windows and Linux insecure? They don't have anything like SIP. Also, the whole idea of SIP has a strong https://xkcd.com/1200/ https://xkcd.com/1200/ vibe.
    - warkdarrior 6y ago
      Windows has Windows Resource Protection (previously known as Windows File Protection) with same goals as SIP. SELinux for Linux can achieve similar levels of protection.
      - Wowfunhappy 6y ago
        Windows Resource Protection doesn't prevent code injection, and can be disabled from within the OS. I don't consider them equivalent.

1996 6y ago

An M1 MBA running Windows 10/ARM? I'd buy that right now!

sys_64738 6y ago
Who would write the Windows drivers for the M1 SoC?
- blinkingled 6y ago
  That would have to be Apple just like Bootcamp. It's not just drivers - there's also bootloader and firmware.
  - threeseed 6y ago
    Bootcamp very much belonged to a different era where having access to Windows apps was important in particular in the enterprise space. These days everything has moved to mobile and web apps that I can't imagine they will bother investing the substantial effort to port the drivers across. Especially since Microsoft doesn't seem to take Windows RT all that seriously.
  - Wowfunhappy 6y ago
    People hacked Windows onto early Intel Macs before Apple made it official with Bootcamp!
    - wolrah 6y ago
      > People hacked Windows onto early Intel Macs before Apple made it official with Bootcamp! Slightly different there though, considering that the early Intel Macs were more or less identical to contemporary PC laptops internally other than the lack of BIOS compatibility mode. Drivers would be much more challenging in this case.
  - skissane 6y ago
    Microsoft should offer to fund the driver development – either develop the drivers themselves, or pay Apple to do it (this assumes that Apple would be willing to cooperate with either option.) Getting Windows ARM to work on Apple hardware would do a lot to build mindshare on Windows ARM and contribute to the success of Windows on the ARM platform. Microsoft needs this much more than Apple does.

ogre_codes 6y ago

> Make a downloadable Ubuntu ISO with drivers and firmware integration available that works as a fully functional alternative OS If Apple were to do it, it would make a lot more sense to release a version of Darwin with all the drivers.

alwillis 6y ago

I am well aware none of it will actually happen but nonetheless it would get more people to buy into what seems to be an excellent hardware platform. Apple had a record Mac quarter (July-September), generating a little over $9 billion in revenue; Mac sales were up 37% from the year before. A lot of this was due to people buying Macs to WFH during the pandemic. But it also shows they don't have to change what they've been doing to keep sales going. I suspect when Docker gets running on M1 Macs, a lot of the need to boot into Linux will dissipate. Same thing when Linux running in a VM on Apple Silicon Macs is much faster than any comparable PC hardware you can buy. Remember, they demoed Debian running in a VM on a prototype M1 Mac nearly 6 months ago, so we know it's coming. And while I get it—I used to help support a lab of triple-boot Macs (MacOS/Linux/Windows)—being able to boot 3rd party operating systems on manufacturers machines is going to become less common. With the goal is to diminish the attack surface for the bad guys, my hope is Apple's hypervisor technology will enable access to enough things to create a fast, workable VM solution for 3rd-party operating systems on M1 Macs without sacrificing security.