Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
"Direct" booting of other OS's on Arm based Macs will not be supported
- Thread starter ifrit05
- Start date
- Sort by reaction score
Makes sense unfortunately. Even the ARM version of Windows would require a decent amount of investment from Microsoft to get it to run properly on the machine. Apple's SoC is so different to anything else.
I think either dual machine or a quiet Intel box in the corner and use Remote Desktop is the way forward. I'd be keen to see if Apple/third parties releases things like compatibility cards for the ARM Mac Pro, as in the days of the old DOS compatible Macs. An Intel chip + RAM + SSD on a PCIe card which allows you to run Windows inside a Parallels type application.
Or even one of those computers from Intel that's a USB pen drive with a full computer on that plugs into a HDMI port on your TV.
I think either dual machine or a quiet Intel box in the corner and use Remote Desktop is the way forward. I'd be keen to see if Apple/third parties releases things like compatibility cards for the ARM Mac Pro, as in the days of the old DOS compatible Macs. An Intel chip + RAM + SSD on a PCIe card which allows you to run Windows inside a Parallels type application.
Or even one of those computers from Intel that's a USB pen drive with a full computer on that plugs into a HDMI port on your TV.
It isn't just that Apple probably doesn't want to be the supplier of Windows machines, but direct booting is impossible with any code that is compiled for Intel, and that includes Windows. MS would have to recompile to the ARM instruction set to get a binary to work which I don't see them doing, UNLESS, there is lots of money to be made someday. And, while recompiling single use apps and utilities would be/is usually dead simple, a whole OS would take lots of time. (and Time = Money) Heck, MS has enough trouble just making Windows work on PCs.
Yes, I am well aware about CPU archecture differences, I was just wondering when and if they were going to announce this.
I suppose it's time for Micro$oft to bring back Virtual PC, we knew that bought it for a reason
Microsoft usually bought to embrace, extend and that other e. RIP, VPC.
Yes and they give it away for free. What if they made a version for Apple Silicon machines and included x86 emulation in it. You could run windows on your new Mac with a full Microsoft stack. Or they could just make it for Apple Silicone and allow people to buy the ARM Windows 10 version. It's not great now but it will be feature complete by the end of the year.
The new “reduced security” mode can boot unsigned OS’es, and as security can be set per drive/partition it will not affect others like your main OS. But Apple will never openly support or encourage this for obvious reasons.
But to boot a custom OS someone has to write a custom bootstrap code to load it. Then the next obstacle is the custom components including what’s on the AS SoC, drivers have to be written. Even the kernel would have have modifications just for the scheduling between power saving and performance cores.
I’m convinced there will be effort to make Linux run on the new macs, but to realistically expect to have any good effort out of Windows on ARM I much doubt.
Anyway most Linux software is open source and usually easily compiled to run natively on Mac including the new Apple Silicon. And if not virtualisation and containerisation will work.
But to boot a custom OS someone has to write a custom bootstrap code to load it. Then the next obstacle is the custom components including what’s on the AS SoC, drivers have to be written. Even the kernel would have have modifications just for the scheduling between power saving and performance cores.
I’m convinced there will be effort to make Linux run on the new macs, but to realistically expect to have any good effort out of Windows on ARM I much doubt.
Anyway most Linux software is open source and usually easily compiled to run natively on Mac including the new Apple Silicon. And if not virtualisation and containerisation will work.
The Intel transition was announced in June of 2005. The first Intel Macs (17" and 20" iMacs and 15" MacBook Pro) were announced in January of 2006. Boot Camp wasn't announced until April of 2006. Up until that point, Apple's official stance of running Windows was that they wouldn't do anything to support or enable it. They issued a firmware update to the Intel Macs that had come out up until that point (so, basically the ones I mentioned above plus the first Intel Mac mini) to enable BIOS emulation mode on their UEFI implementation, and then the beta of Boot Camp Assistant (which wouldn't exit beta until the release of Mac OS X 10.5 Leopard).
It's not unreasonable to expect that something similar could happen here, especially if the outcry is loud enough.
That said, it's a very different scenario. x86 and x86-64 Windows 10 will never get native boot on ARM64 no matter how much Apple and Microsoft try to work it out. Apple and Microsoft COULD make it possible to dual-boot Windows 10 for ARM64. If the virtualization is so good on ARM, then it may really not be necessary. Even if Apple made it seem like it was dual-booting, they might just add a layer in the boot process that is still technically using a hypervisor in which case Apple's claim would still hold. There's a lot to the nuts and bolts that may be different and we're still here thinking about things in terms of Intel Macs.
The short of it is that the only thing that I'd outright rule out is x86 and x86 64-bit versions of Windows 10 natively booting on ARM Macs. I'd bet every Mac I own and ever will own that will not ever happen. Will there be an ARM-native virtualization program that emulates x86 OSes? I'm skeptical, but I don't think anything has been said to dismiss the possibility of that happening.
As for Windows 10 on ARM64 running on an ARM Mac in some capacity, I'd say anything is still possible, especially since the ARM transition has only been public knowledge for less than a week.
I just checked, they only have an ARM64 version of Ubuntu Server that's new to 20.04 LTS. There does not seem to be a standard ARM64 version for regular Ubuntu yet. Doesn't mean there won't ever be one, but it's certainly not as ready as Windows 10 on ARM64 or macOS 11 on ARM64.
Unsigned is different from expired signatures. The screen shot presented says "ever trusted".
https://forums.macrumors.com/thread...ring-mode-replacing-target-disk-mode.2242897/
The loophole to skip all signatures is what T2 has when crank security down all the way. So far it appears that Apple is closing that one for now. What is somewhat up in the air is whether something will get signed by Apple that isn't macOS . For the moment they aren't saying that.
The security isn't set per "partition" but by volumes. All macOS installs at this point are APFS. macOS doesn't have to go into another partition. In fact, Apple encourages in Diskutility to create a volume in a APFS container instead of a partition. Using APFS container volumes and getting rid of partition has been a recommended path for a while now.
If it is a non macOS operating system not on APFS then need a partition, but Macs are primarily built to run macOS.
That isn't the issue. T2 and the future Apple Silicon Macs all do secure boot. Even your alterative bootloader will not be loaded if it is not deemed secure enough. The issue is more so getting your other bootloader to pass security, not writing it. Apple checks the UEFI code before letting anything run. It is a validated security chain all the way down to the hardware.
The major issue is that Windows 10 has its own "valide the boot chain down to hardware" secure boot process. So Apple and Microsoft would be involved in that dance is done. Similar if someone was trying to create a type 1 Hypersor ( e.g., ESXi or small Linux distro with just KVM up and running. ) then would need to get Apple to sign their creation.
iMHO, I think Apple is more likely to sign a couple of type 1 hypervisors than to jump through the Windows hurdles. Bootcamp was a bigger issue when virtualization didn't have built in hardware support. The processors now versus what was avialable in 2006-7 are just vastly different as performing the kernel call virtualization tasks. Most apps aren't going that much faster in "bare metal mode". ( yes there are some. low level , heavyweight, 3D GPU workloads are one. )
Lots of other ARM implementations have Big.Little ( mix of high and lower performance cores). That part of the scheduler should already be there in a decent kernel that has already been ported to ARM. The Apple GPU is probably more of a porting issue.
A Linux hypervisor from 1-3 vendors. Yeah. Mainly so that Mac could be deployed in cloud service nodes. But generic Linux distro 42 from some source bundle Apple never saw.... I am not so sure. I would put Windows ARM in front of that in terms of probability (if Microsoft decided to put effort into getting signed. )
The latter part appears to be where Apple is going. There is improved hypervisor support in macOS ( type 2 so it run on top of macOS). Someone (maybe even Apple) could compose a small , stripped down macOS that just runs that hypervisor service on macOS. (same thing some folks do with stripped down Linux with KVM as a 'free' hypervisor base) . Then folks just pile whatever set of VMs on top of that small-ish macOS and call it a day.
The new boot system has a stripped down macos called "System Recovery". Wouldn't be much of a stretch to tweak that so it had the hypervisor framework plus just its dependencies loaded. ( probably not equiv but would be somewhat like Microsoft's Hyper-V with only incremental work by Apple on what they already have done. )
Some stuff like Docker is sticky coupled to Linux so a Linux base hypervisor is a little "cleaner" (with respect to nesting/layering ) . How much Apple wants to get looped into some type 1's ( VMware , and foudation of some of the bigger cloud vendors) is probably something they are puzzling. For example,
Try MacStadium Orka + 50% off cloud-hosted Mac minis - 9to5Mac
MacStadium is offering 9to5Mac readers can get 50% off the first six months of its cloud-hosted Mac mini subscriptions with code WWDC2020.
9to5mac.com
MacStadium buys a truckload of Macs and if they don't have a way to deploy Orka then Apple has distrupted a pretty big mac buying business. They have gotten that to work to T2 macs but if Apple closes the path they used to get that to work then it is a problem.
My only complaint is Apple unilateral decision to further lock down the computer. The writing was on the wall, with the latest set of MBPS which prohibited Linux from being installed onto the internal drive (even with relaxing the T2 security settings). So, it comes as no surprise. Of course with the move to ARM, what other viable OS is there? I'm not sure how robust the ARM Linux scene is.
As pointed out hardware virtualization support in CPUs sucked in 2008-7. It is like pointing back to the era when CPUs didn't have floating math parts and saying needed to get a FP co-processor to get better math computation bandwidth.
At this point virtualization works much, much , much better. If enable IOMMU lsolation with pass through well enough can even get low overhead GPU access to the guest instances.
It is not two decades later and it isn't unreasonable to expect that Apple will provision the tools that are available two decades later. A "PC" doesn't have to be a generic box with slots anymore. Same thing with booting down to the raw metal. There is gobs of activity that doesn't depending on that.
[automerge]1593263258[/automerge]
Android is layered on top of what kernel? Linux. ChromeOS? Linux. Recent #1 of TOP500 supercomputer list ? Linux. Amazon Web Services most Graviton2 instances ??? Linux. Raspberry Pi ? Linux.
Robust? (as in 'wide variety' ) ... that is pretty much covered. ( unless "robust" means number of desktops )
Large Desktop deployments .. not much yet.
Avantek's Arm Workstation: Ampere eMAG 8180 32-core Arm64 Review
Last edited:
I think that in the future Apple will support some way to use Windows or Linux on a Mac. They've supported Windows for 14 years.
They already showed Linux running through virtualization running Apache I believe, so I know that Apple's at least a little bit interested in supporting these OSes.
They already showed Linux running through virtualization running Apache I believe, so I know that Apple's at least a little bit interested in supporting these OSes.
Apple has said explicitly that you will be able to use csrutil to disable Secure Boot. There is no longer an option in the graphical user interface, but you will be able to do this via the command line. Of course, you still need a compatible OS that runs on ARM Macs.
It's also not true that Apple has ever prohibited Linux from being installed. Apple did not provide any Linux driver for the T2 SSD controller (while they did provide a Windows driver for use with Bootcamp), but you could always disable security and boot Linux, even on the latest set of MBPs. However, Linux was not able to access the internal SSD because of the missing driver. By now, the Linux community has developed a driver and you can now install Linux on the internal SSD of your latest MBP, if you like to:
MacBookPro 15,1/2? · Issue #71 · Dunedan/mbp-2016-linux
Any support/documentation for the refreshed 2018 MacBook Pros? I have one and I'll be willing to help with tinkering stuff especially since they are using the new T2 chips.
github.com
(The driver has not yet been included in the official Linux kernel, so it's a bit complicated to install it, but it works.)
So as you can see, while Apple did not do anything to make it easy for users to use Linux (like providing drivers), they never locked down the Mac so that it would be impossible to boot another operating system (the way they lock down iPhones and iPads). And now they promised that nothing would change by their move to ARM, except that they will no longer provide drivers for Windows, either.
Last edited:
MS hasn't compiled Windows to ARM instructions? Huh, how do you think this system works ?
https://www.microsoft.com/en-us/p/surface-pro-x/8vdnrp2m6hhc?activetab=processor
Microsoft having a Windows ARM ready isn't the issue. Licensing is the issue, not the "technology". There is also a mismatch of boot security methodology between Apple and MS. (that involves some tech but licensing and "approvals" are also just as deeply involved. )
Microsoft Makes Windows 10 on ARM Available Virtually - Thurrott.com
With Windows 10 version 20H2, Windows 10 on ARM will finally support Hyper-V. But the system was never available virtually.
www.thurrott.com
Errr? Where. csrutil can configure the Secure Boot setting. The but there are only two options presented so far "Full Security" and "Reduced Security". So far the new "Reduced Security" mode still requires that Apple signed the OS at some point in time. ( it can be an expired or perhaps a signature attached to another system , but still was signed at some point. ). Cranking down system integrity protection can get 3rd party kernel extensions, but won't crank away something not signed completely.
Signed by Apple Linux perhaps, but so far the Apple Silicon Macs have even tighter security requirements. (perhaps temporary fall out in the DTK due to using an iPad Pro chip as a stand in for a "broader ability" Apple Silicon SoC. But along the lines of where Apple has been going and very aligned with where the iPhones/iPads have been. )
Last edited:
Look here:
Explore the new system architecture of Apple silicon Macs - WWDC20 - Videos - Apple Developer
Discover how Macs with Apple silicon will deliver modern advantages using Apple's System-on-Chip (SoC) architecture. Leveraging a unified...
It's obvious that when they describe how you can use csrutil to configure Secure Boot, they do not just refer to the possibility to enable "Reduced Security". They explicitly say that you would want to use csrutil if you develop kernel extensions. In "Reduced Security" mode (which they describe earlier), only notarized kernel extensions would run, so those cannot be the same modes.
And if for some reason csrutil would allow you to run your own kernel extensions, but would prevent you from booting other operating systems, it would be trivial to write a kernel extension that boots another OS. (Therefore there's absolutely no reason for Apple to allow the development of kernel extensions while preventing the launch of other operating systems in the first place.)
Also, when John Gruber asked Craig Federighi where the rumors are coming from that Apple would use the ARM transition to further lock-in developers or users, Federighi says:
That would be really dishonest if he knew exactly that Apple would use the switch to ARM to lock down the bootloader.
[automerge]1593266524[/automerge]
That's why I included the link to the T2 driver in my posting. With that driver, you can install Linux to the internal drive as well. It has always been an issue of missing drivers, never one of Apple locking down anything.
Look here:
starting at 19:10 (or 18:50 for reduced security mode).Explore the new system architecture of Apple silicon Macs - WWDC20 - Videos - Apple Developer
Discover how Macs with Apple silicon will deliver modern advantages using Apple's System-on-Chip (SoC) architecture. Leveraging a unified...developer.apple.com
It's obvious that when they describe how you can use csrutil to configure Secure Boot, they do not just refer to the possibility to enable "Reduced Security". They explicitly say that you would want to use csrutil if you develop kernel extensions. In "Reduced Security" mode (which they describe earlier), only notarized kernel extensions would run, so those cannot be the same modes.
None of thoe csrutil options turn off the requirement for an Apple signed OS . Apple has also told folks in this and other session to get off of legacy kernel extensions because it is going away. it is there no because some stuff is more slowly going to move over and probably needs more time , but it is on its way out.
Turning SIP on/off , adding a kernel extension ( temporary signed or notarized for deployment) , etc. none that changes the signature status of the core kernel code that Apple wrote and signed. Apple isn't completely locking every and all possible edge cases down. But they are super serious about protecting the initial boot process because there is lots of privacy/security infrastructure layered on top of that.
I guess you misses the part of the video at 6:44 of the video talks about security. Kernel Integrity Protection makes the kernel immutable. ( self modifying code is horrible bad security kernel code. There is approximately zero good reason for self modifying code to be in the kernel . None. ) Write X^R makes it kind of hard to eat the scheduler when it still may be running and not get a horrible system crash. In short, Apple has added very substantive hardware to make that harder; not trivial. And real bootloaders (or type 1 hypervisors ) don't need that kind self modifying code. So these hardware additions don't block them , just a large class of kernel subversion security holes.
Why? Because that is not what kernel extension are suppose to do at all. Kernel extensions the "eat" other parts of the kernel are grossly untrustworthy.
The kind of gross perversion is why they will get retired over time. Easy attacks on the security code of the operating systems is exactly what Apple doesn't want to allow. Folks "extending" the system or understanding how it works better is what they want to continue to enable.
Sicking a "man in the middle" of the OS to pilfer through people's private data ... no. That isn't in their long term plan of enabling.
he outlines kernel extensions , but no where in there does he suggest "hobbyist" undoing , modify, circumventing Apple security on the Mac done at the secure enclosure level. Apple isn't giving folks direct access to the firmware because that is a root of trust security trust vector that is foundational to their own code. Hobbyist code that wants to get along with Apple Code? OK. Hobbyist code that think Apple code should be casually tossed aside? There is nothing above that lines up with that. Kernel extensions are suppose to "extend" the kernel; not subvert it to a boarder set of security hole vectors.
The key quote there is that Apple is interest in advancing security. Not going backwards. Where that runs into conflicts with hobbyists then the tie breaker is probably going to go to "advancing security" .
Apple doing per device IOMMU mapping so that does not have willy nilly access to the kernel is exactly one of those advancing security moves. It allows better extensions. And fewer rogue disruptors. The primary instance of the firmware being controlled by the 'boot/security separate subsystem" and only a copy of boot firmware presented to the host CPU. Again trusted extensions not blocked. Rouge disruptors blocked.
There is nothing dishonest in his statement because the collective statement doesn't put security on the far burner for Apple. It is there on the front. It helps to not cherry pick out the parts you want to see and ignore the rest that are highly relevant.
Apple had a security disconnect problem with external drives the T2. So they had a cranked down mode where wasn't secure and more open to external. This iteration they folded external drives (with signed OS) into the Full Security mode. That is an example of "advancing security" and a broader range of user objectives at the same time. That is illustrative of what he is talking there in that quote.
The bootloader is only locked in in that have to be signed to boot. Other trustworthy folks stuff could get signed.
He also comments in the video about how having a modern virtual machine means that folks can run a wide variety of other OS on top of the secured boot process that Apple provides. There is a bit of a door there for perhaps some other type 1 hypervisors getting signed. Or some other OS that goes through Apple's trust process far enough to get a signature.
Ok, so how do you know that? Apple never said anything like that. I stated my reasons why I don't think that's the case.
Let's say they would allow people to turn off Secure Boot completely. How would that compromise security (for normal people who don't use the option)? There's only one thing that would become easier: If you have physical access to someone else's Mac, you could disable Secure Boot, modify their system (without having to modify the hardware) and they wouldn't notice. But Apple could also display a prominent warning message on boot if Secure Boot is disabled. Then hobbyists could develop another OS (and ignore the warning) and for everyone else, you have a similar level of security. I don't know if Apple would do it this way, but I don't see a reason why they need to enforce Secure Boot in order to "advance" the security of the Mac.
No, the key quote (which you left out) is "I think those guys are being total tools". If you know you are in fact locking down the bootloader and someone asks you if there's anything that would explain why people fear you were "locking in developers or users or both", you could say something like: "Maybe it's because we will only load signed operating systems on the new Macs, but that's actually a good thing because..."
It would be really shameless to instead laugh and call those people "total tools".
But I think at this point we should simply wait and see. As Craig Federighi said: "I want people to look at these Apple-Silicon-based Macs and judge us by our deeds."