Use macOS Recovery on a Mac with Apple silicon
support.apple.com
support.apple.com
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.
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.
SELinux for Linux can achieve similar levels of protection.
But I generally agree—power users should feel fine disabling SIP.
This relates closely to the likelihood of future PCs with Microsoft Pluton^ firmware as well. I assume that Microsoft saw the writing on the wall about secure OSes and remote education and online testing and is repurposing their Xbox anti-tampering system for Windows before they get locked out of that market by Apple Silicon.
It’s not about disallowing you from tampering, or about blocking third-party operating systems — it’s about attesting whether or not you are able to tamper, in scenarios where a remote third-party has no physical access to your system. The Linux secureboot shims probably will not be sufficient to earn ‘tamperproof’ as they boot arbitrary unsigned code with tamper-capable privileges via /sbin/init or whatever.
^ via crypto-signed attestations by the Apple firmware+OS, working in tandem to attest that the stack is not and cannot be tampered with as currently booted.
^ https://news.ycombinator.com/item?id=25123990
EDIT: Apologies, the missing paragraph connecting to the parent comment is —
IT departments will begin updating SSO/MFA systems to require, when deployed hardware permits it, the tamperproof attestations. This will protect them from the liability risk of employees turning off key security protections such as SIP, and may result in Apple Silicon being widely adopted by sensitive industries such as banking and IT once they realize they can reduce their risk and liability insurance costs by doing so.
Requiring a reboot to rescue mode to disable SIP is sufficient to block most social engineering attacks that would otherwise have you click through dialogs to bypass it. A dedicated attacker can still overcome this, and once they do, they can impersonate you readily.
If the computer can attest that it's unmodified, then it's possible to throw up alarms for non-expert users when their computer is in that state. I don't think most websites will bother, but those that care sure would love to be able to do so. None of this is specifically for the benefit of users who want to hack the software internals of their computers, though — but those are not the target market for security practices today in any case, since they can overcome literally any barrier prior to this that says "please secure your device before entering".
Still, from an IT standpoint, it sure would be nice to find out how many expert technical users are lying about keeping their system in secure mode when they have privileged access, because they don't think it's necessary and they don't see any harm in lying about it. I'm guessing it's something like 10-20% of all IT admins using unmanaged devices. We'll find out soon enough!
Then what's the point of things like passwords and fingerprint scanners?
> Having the computer be able to attest that it's unmodified means that it doesn't have to mistrust you so aggressively, relative to today.
How so?
> Requiring a reboot to rescue mode to disable SIP is sufficient to block most social engineering attacks that would otherwise have you click through dialogs to bypass it. A dedicated attacker can still overcome this, and once they do, they can impersonate you readily.
We need to lock people out of their own computers to protect them from social engineering?
> I don't think most websites will bother, but those that care sure would love to be able to do so.
In practice, this will end up just like the abomination that is SafetyNet on Android, where if you take control of your own device, you can't use Netflix, Snapchat, Pokemon Go, Super Mario Run, Android Pay, etc.
> keeping their system in secure mode
Really? "secure mode"? What kind of attacks specifically would this prevent that an IT department would care about, as opposed to Hollywood/RIAA/etc. caring about?
0: https://developer.apple.com/documentation/devicemanagement/s...
1: https://docs.microsoft.com/en-us/mem/intune/protect/complian...
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.
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.
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.
I don’t think Apple would really gain anything by refusing cooperation, especially if Microsoft were willing to pay for it. Only a small number of customers will be interested in running Windows on Macs, and Apple gets just as much money from a Mac running Windows as from a Mac running macOS
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_In...
[2] https://docs.microsoft.com/en-us/windows-hardware/design/dev...
[3] https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR...
[4] https://chromium.googlesource.com/chromiumos/docs/+/master/d...
[5] https://www.microsoft.com/security/blog/2020/11/17/meet-the-...
[6] https://techcrunch.com/2019/11/05/google-opentitan-secure-ch...
[7] https://redmondmag.com/articles/2020/06/11/windows-server-ha...
[8] https://www.computerworld.com/article/3528302/the-mess-behin...
[9] https://www.zdnet.com/article/microsoft-secure-boot-key-deba...
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.
If Apple were to do it, it would make a lot more sense to release a version of Darwin with all the drivers.
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.
It's still nice to see a thorough official writeup, and it will be interesting to see what the hobbyist hacker community comes up with.
Craig was saying that they wouldn't "support" booting other operating systems and wanted people to use VMs, but this was widely misunderstood as him saying that Apple would actively not support instead of passively not supporting other OSs.
Also, to unlock your Mac: 1. `csrutil disable` to disable SIP 2. `sudo spctl --master-disable` to disable Gatekeeper and allow apps from anywhere
And finally, the whole thing about MacOS Spying on every app you opened and bypassing VPNs - turns out, both stories had some fake news to them. It was actually the developer certificate (not the actual app), and Apple has announced they are building a new protocol with more failsafes to prevent a repeat of the previous incidents. As for the "bypassing VPNs," that's actually not true at all. System-wide VPNs still do work in Big Sur, it's just that the API that Little Snitch used for app-specific traffic redirects doesn't work on system apps (although system apps still respect system-wide VPN settings).
> To allow installation of software that uses kernel extensions, select the “Allow user management of kernel extensions from identified developers” checkbox.
It is spying, even if there is exaggeration and minimising of the facts from both sides. The new macOS cripples all application firewalls to ensure that no Apple service can be prevented from spying on you, even if you don't want to.
This is conspiracy theory at this point. The benchmarks showing the performance and battery-life improvements are a logical explanation to why they moved to their ARM chips.
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
No, it isn't, but I am sure Apple would like all of us to think so. The new macOS already cripples firewalls to ensure that Apple can spy on you better and retain even more control over your device. Lack of drivers for Apple hardware means that you can only run their OS on it. The frog is being boiled ever so slowly, while also being given Kool-aid to make them think everything's fine. /s
It clearly indicates the direction they are moving towards - you need to change both the software and the hadware to create a closed system like ios. The example I cited about crippling the firewall is the changes made to the software towards this goal. The move to ARM processors is the hardware change to this same goal.
Apple's profit margins have been pretty consistent for the past 20 years. That isn't going to change now. Though it's likely looking at the performance numbers Apple will make more profit due to increased sales.
> but also to exert even more control over Mac desktops
Well yes, but "more control" in this case means they can do take the CPU in a direction which suits them. Things like moving RAM, neural engine, and Secure Enclave into the main SOC.
> and turn them into ios like spying client terminals where you can't run anything on it not approved by Apple or without their knowledge.
Now we're veering into tin-foil hat territory.
Apple has had plenty of opportunities over the years to take down the Hackintosh community and they never have. In fact Craig even said they fully supported it.
And whilst their Mac devices are secure by default they have always made it possible to weaken the security when needed.
Why would they bother with it when it doesn't effect their bottom line at all? In fact, it benefits them as these users may like the platform and migrate to it.
But to that exact point, if I could get my hands on an ARM Mac Mini, stick Linux onto it, and throw any of a variety of use cases at it? At that power envelope, with Thunderbolt 4, and my own input devices? I would genuinely consider switching away from DIY builds for a while.
(...even more so next year, when WiFi 6E and BT5.2 have also trickled out.)
Apple shutdown all the Mac clones, stopped releasing details about the hardware, etc.
(Mobile is a different case, because allowing third party operating systems might threaten their control of software distribution and its tie-in with the hardware; that isn’t the case on Macs since Apple does not mandate their App Store on macOS.)
And I doubt the ROI is there given how substantial the effort would be to port everything across especially the graphics drivers.
Fucking tragic. The good world falls. Crap capitalist garbage keeps asserting itself harder & harder.
My big concern is that in 10 years+ or so, it's likely my Mac won't be supported by Apple any more and there is a good chance it'll still be running. Right now I'm pretty sure I can still bodge together a Linux distro to run on my old iMac G4 sitting in my garage.
IMO that is where Apple supporting booting alternative OSs is the most important bit. In 10 years (heck maybe 5 years), it's likely many of the drivers and whatnot will have been reverse engineered and we'll be able to boot up Linux and get another 10+ years out of it.
Sure, but the ability to occasionally boot Windows or Linux is nice. I've used both on my Macbook Air for various reasons—mostly games on the Windows side, but also some technical Linux stuff that wouldn't have worked in a VM.
Bootcamp is not migrated yet but it wouldn't require disabling boot security since it's done by apple itself.
1. a BIOS compatibility support module (CSM) for Apple's EFI firmware, allowing legacy bootloaders and option ROMs to be used. (Macs released after the first version of Bootcamp came with a CSM out of the box, while earlier Intel Macs needed a firmware update to provide the CSM.)
2. a collection of Windows drivers for the peripherals shipped in Intel Macs
3. a graphical tool to assist with the process of installing Windows (partitioning, etc.)
Linux never needed (2), and (3) was always more of a convenience than a necessity. The need for (1) lessened over the years as both Linux and Windows gained full support for booting from UEFI without a BIOS CSM, and as Apple's firmware evolved to more closely resemble UEFI 2.x than EFI 1.10.
> To allow installation of software that uses kernel extensions, select the “Allow user management of kernel extensions from identified developers” checkbox.
So good to see it may happen
So it seems unfortunate to have to lower the level of runtime security for OSX, in order to enable booting unsigned software. As they shouldn't be strictly related.