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.
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.
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.
On Apple Silicon, you may lose access to e.g. Touch ID login to websites and Apple Wallet, as Apple’s Touch ID protocol allows^ websites to require a secured+unmodified system partition and Wallet may require the same for anti-fraud purposes. I expect Steam VAC and Xbox cross-platform multiplayer will take note of this someday, too.
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.
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.
This is already here, Apple[0] can report to a MDM whether or not SIP is enabled, and then Microsoft's Intune[1] can use this to allow or deny access to corporate resources (similar to some stuff that Google had in the BeyondCorp paper).
Keeping you secure requires keeping the computer secure from attackers. You can't be distinguished from an attacker, from the computer's perspective. 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.
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!
> You can't be distinguished from an attacker, from the computer's perspective.
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?
You’re already familiar with the difference between passwords and secure computing platforms, as evidenced by the citation of SafetyNet and Pokémon Go, and your use of the phrase “abomination” leaves no opportunity for further discussion, so I will stop now to avoid wasting any more of your time. Apologies and be well.
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.
It's worth noting that macOS without SIP is a bit more permissive than Windows—it allows you to load unsigned kernel extensions, for instance, whereas 64bit Windows will not load unsigned drivers†.
But I generally agree—power users should feel fine disabling SIP.
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.)
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.
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.
> 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.
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.
Would Apple need to cooperate in the situation where Microsoft was developing the drivers? I'm sure documentation would be helpful, but in the event that Apple doesn't give it... I don't know. Seems to me it would make sense for Microsoft anyway.
Well, they probably could reverse engineer how any Apple-specific devices work, in the absence of documentation or other assistance from Apple, but the added difficulty of doing that may put them off it. So whether Apple is willing to cooperate may be decisive in practice.
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
True, but there is a widespread misbelief because of the misquoted Craig Federighi that only macOS would be allowed.
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.
I mean, if Apple doesn't release any drivers for its hardwares, then it is effectively true - you won't be able to run anything other than macOS on it and will have to depend on VMs for other OSes. Let's not forget that Apple moved to ARM Macs not only for increased profit but also to exert even more control over Mac desktops 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.
> Let's not forget that Apple moved to ARM Macs not only for increased profit but also to exert even more control over Mac
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.
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
Doing those things doesn't require moving to a new architecture. They can do those things perfectly fine on the current Intel systems. So your point is pure conspiracy theory.
> Doing those things doesn't require moving to a new architecture.
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.
You can change the hardware without changing the cpu. Apple added the T2 chip to Macs that locks down the system just as much as the M1 chip, without removing x86.
Yes, but the misunderstanding was that an option like "Permissive Security" wouldn't exist - that you would have no possibility of anything but MacOS. It does exist, but Apple's just not going to help you with that.
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).
Would LittleSnitch now not technically be able to continue using the kernel extensions it relied upon?
> 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.
> Let's not forget that Apple moved to ARM Macs not only for increased profit...
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.
Knowing the future is hard. Knowing how Apple has behaved in the past and how they are behaving currently and extrapolating is much easier. All indications are that apple is doing this to re-lockdown their market.
> All indications are that apple is doing this to re-lockdown their market.
Apple releases are like a Rorschach check for developers. People see what they want to see in them. If you don't like/ don't trust Apple, every announcement is them creeping ever towards locking down everything. I've been hearing this for the past 6+ years.
But here with the M1, they have the perfect opportunity to lock down the system. But they've left the opportunity for people to build and install whatever they want.
They've even said explicitly that if Microsoft wanted to build Windows for the Mac they wanted to.
We can still access a full shell, install home-brew and they've demoed Linux & Docker running on the M1.
We can still install software from outside the App Store.
I personally think it would be in Apple's interest to publish the information required for FOSS drivers or even assist with them. It would help them sell more Macs, but more importantly cement their dominance among developers.
That is wishful thinking - Apple is not known to do anything that can open up their system and breach their walled garden. ARM Macs are designed to turn even the desktops to iPad / iPhones where you have no control or choice.
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.
> Apple has had plenty of opportunities over the years to take down the Hackintosh community and they never have.
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.
I don’t think Mac clones were really comparable. Mac clones were a threat to Apple’s hardware business. Running alternative operating systems on Apple hardware is not a threat to Apple’s hardware business. Apple has been willing to support non-Apple operating systems on their hardware before - Windows via Boot Camp, MkLinux.
(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.)
Right, but this also pretty effectively killed off other OS's on pre-Intel Macs.
Look at the BeOS story. They ported to x86 because Apple stopped sharing hardware details.
Honestly? Strong agree. A huge part of my general distaste for them as a user is rooted in their resistance to standards. (See: Lightning, AirPlay, their fucking keyboard layout that's so shuffled it also breaks default app-level shortcuts that work on every other device and operating system I use...)
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.)
My big concern with my Mac isn't that I want to run Linux (or ack! Windows) on it. If I was buying a PC for Windows or Linux, I'd buy something else.
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.
> If I was buying a PC for Windows or Linux, I'd buy something else.
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.
Oh don't get me wrong, I am very happy Apple is leaving this open enough you can cross boot. But for me personally, it's more about the long term than next month. I suspect it's going to be at least a couple years before someone gets a Linux or Darwin/ BSD build going on this guy regardless.
Initially, Bootcamp for Intel Macs consisted of three things:
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.
I don’t think bootcamp has ever been a requirement to boot into linux on a mac, and I never have used it to do so on various macbook pros over the last ~10 years
I suspect the easiest route would probably be to get USB (or full Thunderbolt) working first, then connect well-supported peripherals through a hub until the built-in stuff can be supported. If Apple's USB host controller uses standard XHCI, then the bootloader is probably a bigger challenge than getting enough drivers to start productively hacking on the system.
Does this actually mean that LittleSnitch could continue to function as is - with the same kernel extensions used until now?
> To allow installation of software that uses kernel extensions, select the “Allow user management of kernel extensions from identified developers” checkbox.
That's been done already; Pongo OS and Sandcastle were running on the devkits, unless some huge change is made to the M1 it should run all the same. Problems so far were lack of device drivers; there isn't even disk access right now because there is no NVME Controller driver made yet (well, except the one in macOS and iOS of course).
Seems unfortunate that to boot something unsigned you have to disable SIP, e.g. once we have a working linux port (I'm sure it won't be long) to enable booting it will reduce my OSX security at runtime [and not just from the boot chain].
I was paranoid for a long time about things like SIP and SecureBoot but think of it this way. What is the likelihood that you are infected by a bootkit versus some 0day that affects your browser? My main beef w/ rootless/SIP/Gatekeeper and these types of technology is that you no longer own your hardware, you are a slave to the HW manufacturer.
Yet at the same time you get roasted on here if you run things as root. It’s pure bs.. Apple has top notch engineering and architecture. Others always follow.. in terms of hardware, but also software
It removes some specific types of security, but System Integrity Protection is a "runtime" protection on OSX. It disables access to various files/etc even as root unless in the right context.
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.
My understanding is that if boot security cannot be established, it's impossible to assert runtime security either. Otherwise, a compromised code in the boot process can also alter how SIP behaves, essentially invalidating its security function.
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.