VMware ditches plans to support EXSi on 2019 Mac Pro

[sunny5]

VMware ditches plans to support EXSi on 2019 Mac Pro | AppleInsider

Virtualization specialist VMware no longer has plans to support Apple's 2019 Mac Pro, the company said last week, dashing the hopes of system administrators eager to run ESXi on the high-end workstation.

appleinsider.com

 

[barbu]

It would be pretty crazy to use a Mac Pro to run esxi anyway, wouldn’t it? Versus white label rack mount options? I dunno, seems a shame to waste a Mac running this software anyway.

 

[jdb8167]

It would be pretty crazy to use a Mac Pro to run esxi anyway, wouldn’t it? Versus white label rack mount options? I dunno, seems a shame to waste a Mac running this software anyway.

EXSi is running on bare metal so it wouldn’t be running MacOS anyway. The reason you might want this is if you want to virtualize MacOS since the license requires that virtualized MacOS must run on Apple hardware. Maybe Apple will modify its license and allow server hypervisor type-1 to virtualize MacOS since the alternatives are pretty untenable for cloud support.

 

[bobcomer]

It would be pretty crazy to use a Mac Pro to run esxi anyway, wouldn’t it? Versus white label rack mount options? I dunno, seems a shame to waste a Mac running this software anyway.

Not unless you want to run a lot of MacOS VM's, then it is perfect for the job.

 

[barbu]

True, I’d overlooked that “exclusive” feature. Still not surprising since surely the Mac Pro will be running apple si next year.

 

[Kung gu]

Yep x86 Macs lose feature support due to Apple sillicon.

 

[Gnattu]

I really hope ESXi could come to Apple Silicon Macs, but it seems to be extremely hard without Apple's help.

 

[sunny5]

I really hope ESXi could come to Apple Silicon Macs, but it seems to be extremely hard without Apple's help.

Most kinds of virtualization are x86 based. Obviously, Apple ditched x86.

 

[bradl]

VMware ditches plans to support EXSi on 2019 Mac Pro | AppleInsider

Virtualization specialist VMware no longer has plans to support Apple's 2019 Mac Pro, the company said last week, dashing the hopes of system administrators eager to run ESXi on the high-end workstation.

appleinsider.com

Would this really even matter? I mean, the 2019 Mac Pro is Intel/x86 based, so it has nothing to do with CPU architecture, and only hardware (if applicable).

However, what they are NOT saying, is that ESXi will not be certified for any new Mac Pros that are Silicon. In short, they just could be giving Intel-based Mac Pros EOL for any support.

BL.

 

[Gnattu]

Most kinds of virtualization are x86 based

Not quite. Virtualization is a hardware technology that allows a CPU to run multiple OS kernel at the same time, not a software technology that depends on a specific architecture. Most mainstream CPU architectures (x86, arm, RISC-V, MIPS, POWER) support virtualization.

And ESXi does have an arm64 release already, but I think they need Apple's help to make it useable on Apple Silicon Macs.

 

[jdb8167]

Not quite. Virtualization is a hardware technology that allows a CPU to run multiple OS kernel at the same time, not a software technology that depends on a specific architecture. Most mainstream CPU architectures (x86, arm, RISC-V, MIPS, POWER) support virtualization.

And ESXi does have an arm64 release already, but I think they need Apple's help to make it useable on Apple Silicon Macs.

Theoretically VMWare could use the technology created by the Asahi Linux developers to boot the ESXi hypervisor instead of MacOS.

 

[deconstruct60]

Theoretically VMWare could use the technology created by the Asahi Linux developers to boot the ESXi hypervisor instead of MacOS.

Theoretical but pragmatically unlikely. The reduced security mode required for that Linux hack puts up a disclaimer from Apple that this mode is totally unsupported for production workloads. ( It is probably mainly a bootstrap backdoor for macOS/Mach kernel developers to bootstrap a new version of kernel devleopment. All of that is "pre-production" workloads). Doubtful a company like VMWare is going to ignore those kind of "danger, will robinson , danger" signs and roll out something with a claim that it is supported/certified. ( Folks can hack ESXi to mostly work on a Mac Pro 2019 , but VMWare isn't actively supporting with an official certification. )


One of the features VMWare Fusion is the ability to run ESXi. For example :

Installing ESXi in VMware Fusion

kb.vmware.com

A far more supported path VMWare could do is a ESXi layer on top of Apple's virtualization framework. Since the M-series Fusion would be running on top of the Apple virtualization framework perhaps there is a way of getting rid of the "middle man" of a EXSi -> Fusion -> macOS layering. Not getting a strictly type 1 hypervisor but if stripped down macOS it could be useful for images that involved a heavy mix of macOS images on a system.

 

[mr_roboto]

Theoretical but pragmatically unlikely. The reduced security mode required for that Linux hack puts up a disclaimer from Apple that this mode is totally unsupported for production workloads. ( It is probably mainly a bootstrap backdoor for macOS/Mach kernel developers to bootstrap a new version of kernel devleopment. All of that is "pre-production" workloads).

I fully agree that VMWare is unlikely to port ESXi to run native.

However, on a tangent, having read some of the twitter discussion by current and former Apple employees who worked on it, that reduced security mode really is intended to support use cases like running alternate operating systems. They put a lot of thought into how to design a secure-able back door:

https://twitter.com/i/web/status/1339914714055368704

Basically, when you do this, you're attesting to recoveryOS that you, the physically-present password-verified administrator of that Mac, believe a specific file is safe for Apple's Secure Boot to load and run. It's not explicitly spelled out in that particular twitter thread, but when you do this, recoveryOS stores a cryptographic hash of the file in the Secure Enclave. In the future, each time you boot that file, Apple's Secure Boot code cryptographically verifies it hasn't changed since you attested to its safety.

That makes it possible to securely boot a third party OS like Linux without Apple having to sign everything in the chain. So long as you're really sure you're not making a mistake when you attest to the safety of the Linux bootloader, and the rest of the Linux-provided bootloader chain has secure signing checks, you can have a chain of trust all the way from the M1's immutable (stored in mask ROM) stage 0 bootloader to the Linux kernel. Pretty slick, IMO.

The reason Apple puts up those warnings is that you're telling the computer you want to bridge from Apple's chain of trust to somebody else's, and there is no way for Apple's code to tell that the user isn't just being social-engineered into installing a copy of MalwareOS. They've made it scary and obscure enough that even naive users are likely to stop.

(another notable thing: With this scheme, provided you have FileVault enabled, there's zero degradation of security for your macOS installation(s) just because you wanted to set up a Linux partition. That's a big step up from T2 Macs, where you had to completely disable Secure Boot to run any OS not signed by Apple.)

 

[deconstruct60]

I fully agree that VMWare is unlikely to port ESXi to run native.

However, on a tangent, having read some of the twitter discussion by current and former Apple employees who worked on it, that reduced security mode really is intended to support use cases like running alternate operating systems. They put a lot of thought into how to design a secure-able back door:
....

The reason Apple puts up those warnings is that you're telling the computer you want to bridge from Apple's chain of trust to somebody else's, and there is no way for Apple's code to tell that the user isn't just being social-engineered into installing a copy of MalwareOS. They've made it scary and obscure enough that even naive users are likely to stop.

The text of bputil's man page (and the warning it spits out) reads as the following

"This utility is not meant for normal users or even sysadmins. It provides unabstracted access to capabilities which are normally handled for the user automatically when changing the security policy through GUIs such as the Startup Security Utility in macOS Recovery. It is possible to make your system security much weaker and therefore easier to compromise using this tool. This tool is not to be used in production environments. It is possible to render your system unbootable with this tool. It should only be used to understand how the security of Apple Silicon Macs works. Use at your own risk! "

To characterize that text as being "obscure" is over selling something that it is not. The text is not obscure at all of getting Apple out of any liability ( "own risk! " ) . It very clearly states to not to use this in production environments. I'm not sure how that could be an anymore direct statement; not ambiguous at all. it is pretty clearly not really aimed at the naive because it waves off even folks who are sysadmins.

The "possible render system ubootable" ... yeah that part is 'scary' and somewhat nebulous obscure.


I don't think this is waiving off the naive. It is designed not to block those dogmatically determined to do what they want to do not matter what Apple says. This probably will serve as an excellent " stream blow off , relief value" to dramatically drop the number of folks looking to poke holes in Apple's security system to get around a tighter restriction. Those who want to do experimentation also probably walk through the "door" here also. ( experimental phase is before production phase ).

However, folks with strict and high liability service level agreement contracts or support contracts that have deep pockets to protect probably are far from "naive" and yet will stay far away from this mechanism. VMWare is avoiding prematurely enabling Windows 10 without Microsoft's permission. They ( and other multibillion dollar ) companies are not going to tell hordes of users to blow past a screen that Apple tells them don't go through.


the targets here are suppose to be in some designated APFS volume (and mach-o binary). Not technically restricted to a Mach/XNU binary but sure has to reside where one would likely "live".

(another notable thing: With this scheme, provided you have FileVault enabled, there's zero degradation of security for your macOS installation(s) just because you wanted to set up a Linux partition. That's a big step up from T2 Macs, where you had to completely disable Secure Boot to run any OS not signed by Apple.)

It is probably not zero degradation. It is minimal. Apple doesn't have quantum proof crypto. And likely holes somewhere . The T2 chip was "bullet proof" right up until it wasn't.

 

[jdb8167]

The text of bputil's man page (and the warning it spits out) reads as the following

I’m fairly certain you don’t need bputil to boot an alternate kernel. You just need kmutil.

 

[mr_roboto]

It is probably not zero degradation. It is minimal. Apple doesn't have quantum proof crypto. And likely holes somewhere . The T2 chip was "bullet proof" right up until it wasn't.

Say you have two operating systems installed in two different APFS volume groups - call them A and B. What I'm trying to tell you is that if A is configured as full-security, and B is not, A still enjoys exactly the same cryptographic chain of trust as it would if B didn't exist at all.

Of course it's possible that they have bugs in their implementation. But if Apple's security engineering team knows what it's doing, it's not very likely that setting a permissive boot policy for B somehow cross-contaminates A.

I'll also point out that if you really want to get tinfoil hat about it, never touching bputil can't save you. You're still trusting that Apple's boot code can look up the correct boot policy, cryptographically verify it, and enforce it. These code paths are exercised regardless of whether you ever created a second OS and set it to a lower security mode.