I can’t help but feel UTM pushed Apple to deliver this polished of a solution? Pulling this 100% out of thin air though.
I’ve long thought it would be interesting to release Linux native apps in this sort of wrapper to the App Store.
If you're seeing it use the hypervisor framework, it's possible that's changed since I set mine up and they just haven't seen fit to advertise that change on the web site, which still claims that it's "based on qemu."
(I'm using UTM 3.2.4... just because that's what I used to migrate my data from my old linux laptop to my new mac, and I haven't needed to change it.)
Why the "scare quotes"? Sounds totally justifiable. Third party kernel extensions have always have had issues with both security and stability.
They don't have to be "the only one who knows how to write such bug-free or secure system software".
They just have to disallow a class of potentialy buggy and insecure software running with kernel level access, and that's enough to keep tons of additional attack vectors off the OS.
I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension.
Which is all ok till you consider that experienced developers that make good system software can offer better software than Apple, which often may have no incentive to support softwares that isn't aligned with their business interest. Application firewalls is an example, because they can also prevent Apple software and services from data-mining a users personal data. (You may trust the Apple codebase on which all Application firewalls on macOS are forced to run, but what if I don't and want alternative? And if you say, "Then don't use macOS", note that's a very anti-consumer view and is toss to everyone's consumer rights). Virtualisation is another example where non-Apple options can be better than Apple's as Apple would prefer that you do everything on their OS than use alternate ones. Or when you don't want to use Apple software because of the terms you have to accept to use it.
Not much more "anti-consumer" than "if you prefer formal attire, then just don't buy Levi's - as opposed to insist the make black suits and bow ties".
Though I understand the convenience - I'd like to have the option myself in some cases.
What I dont like is third party companies forcing you to install a kext if you want to use their product, for non essential reasons (that could be handled in userland). At least this forces them to work with userland APIs (looking at the "haxie" peddlers out there).
Instead, in the real world we got vendors that wrote horrible and unstable code that was required by IT departments. For example, instead of implementing a firewall using Apple technologies, in a stable manner, we got an “enterprise” firewall kext that would crash whenever a USB network card was plugged in. And I mean crash the computer. My USB-C dock was absolutely worthless because of this exact issue.
Vendors forced this on Apple. IT departments that were primarily Windows shops would just blame Apple instead of the vendor. Because their software worked for Windows, so why was it only a problem for Apple? I know the IT department at my $WORK had this mentality.
Now at least I have a stable system and I don’t miss not being able to add my own kexts.
Apple definitely cannot write bug-free code, but your claim that third-party software worked fine without issues is factually incorrect. Third party kernel extensions have historically been a major source of instability and crashes.
That's a misunderstanding of what I was trying to convey. To clarify - I was specifically talking about existing application firewalls and VM applications for macOS that use / used kernel extensions and already have a large userbase on macOS. Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Especially when we consider how such a move is also anti-competitive and anti-consumer, and thus helps Apple's business.
Forcing developers to make an expensive migration from their own tried-and-tested and stable codebase over which they have full control, to use Apple's OS API's is a developer hostile move. Even more so when you consider that a developer will now have to rely on Apple to fix bugs or add new features - which Apple may have no inclination to do so so if it feels it isn't aligned to their own business interest (thus anti-competitive).
I personally have been using some of these applications that install custom kernel extension, and my macOS (3 versions of macOS over a period of a few years) has never crashed or become unstable because of them, so far. If an application that used a kernel extension made my system unstable or crashed it, I obviously wouldn't use it and will uninstall it. But completely taking away my choice as user to customise my OS with kernel extensions, and reducing my choices (as a customer) by taking away the ability of developers to offer a non-Apple custom software solution that is better is also obviously anti-consumer.
Thats not what they are saying though. They are saying, when we have official userspace API, we will remove access to the old kernelspace API.
Thats not to say the kext is bad or evil. It is to say you won't be able to accomplish it in a kext using public api anymore.
Were there badly written kexts before? Were there kexts with interactions? Were there kernel API and whole subsystems kept in for years because some popular enterprise product refused to update?
Absolutely. I'll refrain from mentioning the one I had in mind which hit all three checkboxes.
As far as I can tell, nobody has made a third party virtualization solution for Apple silicon nor is anyone really looking to do so. I don't think this conclusion is particularly surprising.
To be clear, I don't believe there is anything wrong with Apple offering built-in OS API solution for applications like firewall, virtualisation, graphic engines etc. The problem is when they say you can only use those and don't allow competition.
When a particular type of software on macOS is forced to use just one particular API, it stunts all such softwares using the APIS as they can't really offer any major distinction and can only offer the limited features the API provides. Worse still is when such practices is actually meant to restrict competition to protect their business interest. For example, it is clear that Apple is pivoting more and more into commercialising user privacy (monetised through its services) and advertising (by data mining personal data through these same services). In such a case, existing softwares that offer privacy protections (like application firewalls and even alternate operating systems on macs) are examples of competing system softwares that impede this goal. Obviously Apple cannot directly ban these softwares without negative user backlash. But it can ensure that such softwares are crippled by forcing users to use limited API's and / or by limiting the operating environment they run on. (The frog is slowly boiling - https://en.wikipedia.org/wiki/Boiling_frog - and we developers and users are slowly losing more a more control over our Apple computers and device).
Apple has great developers and they can surely build a decent hypervisor API solution. But we'll never know if it is the best if no custom alternates are allowed (either due to lack of hardware literature or due to Apple policies restricting such custom alternatives).
Are you looking for https://developer.arm.com/documentation/100942/0100/AArch64-... ?
Access to virtualization features is provided through the hypervisor framework for both intel and apple silicon products. If you have an existing Intel architecture product you might be upset that Apple is going to disable your ability to use virtualization directly via a kext.
But, I have a hard time imagining someone really wanting to use their own hand crafted hypervisor rather than the one Apple built on Apple Silicon for running on Apple operating systems - especially since Apple has committed to providing additional hard things like paravirtualized hardware.