They didn't need to be before in the Intel era of macOS too?
Yes they did. Well, at least they needed to sign 3rd party GPU drivers.
Early on VMWare ( and pretty sure Parallels ) presented a simple SVGA GPU. It is the standard approach to getting up something "old" and basic as a lowest common denominator.
For example for VMWare fusion have to turn off SVGA when want the accelerated graphics.
"...
2. Add the following two lines to the .vmx file:
appleGPU0.present = "TRUE"
svga.present = "FALSE"
...."
kb.vmware.com
Parallels is different setting, but same general approach.
". .. Parallels Desktop has no access to the Mac's device's physical graphics cards. Instead, Parallels Display Adapter driver (which is part of the Parallels Tools installation) interfaces with virtual hardware and provides 3D acceleration features. The actual acceleration is achieved by translating Direct X commands from the guest OS to the OpenGL API on the macOS side. ..."
https://kb.parallels.com/122807
Oracle VirtualBox ( in the Emulated hardware section. )
"...
Graphics. The default Oracle VM VirtualBox graphics device for Windows guests is an SVGA device. For Linux guests, the default graphics device emulates a VMware SVGA graphics device. See
Section 3.6.1, “Screen Tab”.
... "
The virtual machine foundation intercepts all calls to the virtual GPU device and "rewrites" them to call the host GPU using OpenGL or Metal. More of an "emulation" heavy variant of virtualization. The CPU only needs to trap OS system calls.
Similar to other non CPU hardware. USB , Optical Drive , etc. To a large extent trap and emulate.
So what Apple had to do was enable macOS to run on some "lowest common denominator" hardware and allow the virtual machine folks to insert the drivers for their virtual hardware.
There is some vary basic SVGA graphics that are required for EFI. Historically, there is a bootstrap Video BIOS
ihttps://en.wikipedia.org/wiki/Video_BIOS
Not exactly the similar concept of some "floor" graphics driver than can do some relatively simple stuff "well enough" to get to a " real" driver.
To do Linux and Windows all VMWare/Parallels need to do is emulate that UEFI boot process and load their drivers at the appropriate time. macOS Intel version is open to loading drivers at boot. MacOS M-series operates on a much shorter leash.
Did Parallels and VMware not have the same hurdle to overcome with Intel macOS? I could see more industry standard elements (like UEFI) making it easier, but I'd imagine that, at the end of the day, it's still VMware and Parallels faking a proper Mac's firmware and booter (not to be confused with bootloader).
Can;t really "fake" Apple's firmware if it is cryptographically signed and verified at boot. Unless it has changed, the Linux boot hack depends on cracking/jailbreaking the boot system with a hole in the security. That probably isn't a stable foundation for the long term (e.g., when Apple plugs the hole in future systems. )
T2 chip in Intel systems would hand off a copy of UEFI that it had checked to the main system CPU. That is post check though and CPU didn't have access to the primary instance of the UEFI ( copies only). However, there were always non T2 systems whiile T2 systems were around also so there was a "lower security standards" boot path too.
Clone BIOS and UEFI aren't hard because they are basically open boot formats. Apple isn't trying. to be open and actively closes loopholes over time.
When Apple enabled "lowest common denominator" on EFI/UEFI systems they were not trying to swim upstreams in a rapids ( lots more players paying much more money to drive the platform forward. ) That opened to door for easier hackintosh implementations. The upside tradeoff is that they got base system building blocks cheaper.
I strongly suspect that Apple isn't going to write a version of macOS M-series that does not presume that the security enclave is always there. Nor do I think Apple will be particularly thrilled with some virtual Security Enclave storage passwords , kets ,etc in normal RAM.
On M-series binaries in the kernel are locked read only. The VMWare/Parallels drivers can't "eat" their way around Apple's kernel code once it is up and running (barring some glitch in code. ) [mutating Apple's kernel code to make the virtual machine run ... Apple has protections against that. ]
Apple's Hypervisor Framework is relatively super thin ( even for a hypervisor). It basically only virtualizes access to a CPU code execution stream ( a thread/process). the process gets its own virtual memory ( as usual for a user level process) and the framework provides some hooks for when various system traps are triggered by called into kernel to to basic hardware I/O.
It doesn't really cover the bulk of the virtual hardware that the VM software providers had to create. Actually, much of the "easier" stuff that the underlying Virtualization opcodes in the CPU hardware support with a common facade on top.
There was no WWDC session on it but there is some "beta" stuff in macOS 12 to add a bit more "meat" to the barest of bare bones virtual "machine" that Apple does.
"... Create virtual machines and run Linux-based operating systems.
...
class VZMacGraphicsDeviceConfiguration Beta
class VZMacGraphicsDisplayConfiguration Beta
class VZMacHardwareModel Beta
class VZMacMachineIdentifier Beta
class VZMacOSBootLoader Beta
"
Create virtual machines and run macOS and Linux-based operating systems.
developer.apple.com
If Apple does it then they can probably synch it up to their security requirements and implementation. [ for example, if Apple added IOMMU and virtualization support to the Apple GPU then wouldn't really have to do much to "virtual" the GPU. Would be closer to what the CPU cores are doing. ]
Can tell by the primary label on the Framework though that the primary objective has been to enable Linux. ( not some other operating sytsem. ) . that was probably good for a first iteratiion ( APple hasn't been deep in the virtualization of hardware business. Somewhat getting into it because banning everyone else out of the kernel. So they kind of have to take a larger ownership of the foundation support for this. )
P.S. Since Apple has a large cloud services operation they probably do have a significantly large in house , "eat your own dog food" demand to run Linux images on Mac hardware for R&D developer for vast majority of cloud services they provide.
