Frankly, I'm not sure there are any entities I would trust less to be running in EL1/ring 0.
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.
Apple Updates Platform Security Guide, Says Kernel Extensions Won't Be Supported on Future Apple Silicon Macs
- Thread starter MacRumors
- Start date
- Sort by reaction score
I think you are mistaken as more and more companies are using cloud based apps and VM's, it actually makes more sense to have the most secure client system OOTB so there's less to worry about.
Sure,Chromebooks are also an option. But a similar spec Chromebook is roughly the same price of a spanking new MBA M1, with the only real difference being a touchscreen. The Mac can (arguably) run more commonly used business software than the Chromebook, faster. And that's before everyone has optimised their software.
Uhh it’s the same with Windows. Corporations do extensive testing with any new Windows Update. Companies are still on 1809 while they are still testing the newer updates. How is this a Mac issue?
So how is all this affected by the removal of kext extensions? It's not. Controller support is not an issue with the OS it's the apps that need to support it. Similar to the time MS introduced Direct X.
There are multiple Free/Paid SSH Session Managers out there. I keep my configurations in the .ssh/config. MacOS has its own Hypervisor which Docker uses so if any of the other apps don't then that is on them.
ok, I read through this whole thread and still don't understand why allowing an app to use Kext is a good thing and dooms day for all the nay sayers?
Why can't the same be done on software level?
Why can't an app that won't survive without Kext (not sure if there is any of this case), get an approval from Apple to be included in the Kernel by Apple?
Why can't the same be done on software level?
Why can't an app that won't survive without Kext (not sure if there is any of this case), get an approval from Apple to be included in the Kernel by Apple?
Google Drive File Stream is another one, which IMHO there's really no excuse for.
I think many developers have gone the kext route out of laziness, simply because it's easier to code things like file services apps, VPNs, AV software, and so forth. It's not necessary by any stretch of the imagination, but it's definitely easier in many cases.
Google Drive File Stream doesn't work on M1 Macs right now — at all. Google has promised an update is coming in April, but really they've already had almost two years advance notice to get with the program, and every other cloud provider seems to have managed just fine. In fact, even VM developers like Parallels and VMware were able to remove their dependency on kexts back when Big Sur was still in beta, and it was arguably much more complicated for them to address this.
So I think Apple is definitely doing the right thing here. Sooner or later you have to force the hands of developers if you ever want things to change, and it's not like Apple didn't give everyone plenty of notice that kexts were going away.
I'm of two minds about that... As an advanced power user, I'd love to have some user choice in the event that there were things the need to be run as kexts (which I'm not entirely convinced there are — or at least not as many as some developers would like us to believe), but honestly if that choice is made too easy, you just know that there are going to be developers that simply tell users to "enable kext support" before installing their apps because they can't be bothered to code them the "right" way, especially in the case of all of those apps that are already relying on kexts.
Somebody earlier in this thread suggested that turning off SIP would be enough to address this, and I think that's all the user choice we really need, as power users will be happy to deal with that, but it's not something that any sane developer is going to try and instruct average users to do just to install things like cloud file sharing apps, AV apps, or VPN apps.
Honestly, I think there are a very limited number of cases where kexts are genuinely beneficial and perhaps worth the risk, however many low-level apps have been coded to run in that space because it's more convenient for the developers, not because it's better for the end users.
Did that have any effect on the performance of Parallel and VMware, good or bad?
Hard to say just yet on the M1 side, since you can't really virtualize the same stuff you could before, so it's not really an apples-to-apples comparison.
That said, I was running the VMware Fusion preview back during the Big Sur beta in late August — on a 2013 MBP no less — virtualizing Windows 10, Debian, and some older versions of Mac OS X, and I can't honestly say I noticed any difference at all in practical terms, although I wasn't exactly trying to run anything that pushed the machine too hard.
Without a push from Apple I doubt developers would do the extra work to migrate.
I used to be an iOS developer and the programming team often saw Apple's forced deprecation schedule as an ally. It was normally hard to get management to approve maintenance, but imminent loss of functionality if we didn't update always did the trick.
I don't see it as less choices, I see it as replacing bad choices with good choices.
I'm not familiar with File Stream specifically, but based on the name I'll assume it's similar to Dropbox.
There actually is a somewhat reasonable excuse to use a kext for this use case currently: Apple simply hasn't yet provided suitable replacement APIs to do this in user space. The FileProvider APIs in Big Sur are supposed to be the long-term replacement, but last I checked, FileProvider is basically only a Finder integration at this point. It doesn't really hook into the VFS layer like you'd expect, which means you can't access FileProvider-stored content through the normal POSIX filesystem APIs.
Note that FUSE on macOS does not eliminate the requirement for a third-party kernel extension (FUSE itself is a kext). Hopefully FileProvider will become a suitable built-in replacement for FUSE in the near future.
It shouldn't. VMware and Parallels were presumably only using their own kexts to provide a KVM-like interface to use hardware virtualization from user space, and doing device emulation in user space already. (I'd be horrified if they were doing device emulation in the kernel, with the large attack surface it presents.) Apple now provides a similar interface with Hypervisor.framework.
In other words, the proprietary kexts and Hypervisor.framework accomplish the same thing, except that Hypervisor.framework is built in to the OS and moves responsibility for the kernel code to Apple (which, IMO, is a good tradeoff -- I trust Apple to secure this more than I trust VMware or Parallels, even despite embarrassingly high-profile screwups like goto fail).
I think for FUSE-level file systems that makes a lot of sense, but I really don't think it's necessary for cloud storage provider virtual file systems that don't really need to work at such a low level. Dropbox, OneDrive, and others seem to do just fine, and AFAIK they never used kexts in the first place, while there are a few areas in which GDFS actually gets borked because of the fact that it does — fast user switching causes problems, for example, and while I'm not sure that's based on it operating at the kernel level, I suspect that's at least part of it, insofar as it's not inherently isolated to each user session the way that Dropbox et al are.
That said, GDFS does work a bit differently than Dropbox et al under the hood, since it does mount as a virtual file system, while the others just sync to a local folder. However, I'm really not convinced that's in any way necessary — it's merely the approach that Google went with, for whatever reason. My best guess is that it could provide more granular security controls to mirror the cloud storage permissions, especially on things like Shared Drives, but since those have never been implemented beyond a very basic RO/RW distinction, it's ultimately kind of irrelevant. I also imagine the same thing could be done with Finder extensions, although it would be more of a hack.
It depends. For a simple synced folder where a copy of all data is going to be stored on the local disk, a VFS solution is unnecessary and will be less performant than simply watching the filesystem for changes. (A solution that watches the filesystem for changes is asynchronous -- it does not insert itself into the data path like a VFS would.)
However, it looks like GDFS provides on-demand file streaming from Google's servers, where there is no local copy of the data. A VFS solution really is the best way (perhaps even the only way?) to implement that.
I know Dropbox at least at one point was using a kernel extension for the same purpose. I don't know if they still are. Their decision was rightfully maligned at the time, particularly coming from a company that wants access to their clients' unencrypted data and once completely failed to verify passwords. I'd apply the same criticism to GDFS if their kext isn't FUSE or a FUSE-like solution. There are certainly performance benefits to avoiding the context switch, but for an Internet storage solution, network throughput is almost certainly going to be the bottleneck already, and the attack surface of a kernel-based network storage implementation is concerning.
Although not designed for this purpose, I wonder if an Endpoint Security extension could be used for on-demand file access like this. I suppose it would depend on whether there is a timeout for authorization events.
Aha, yeah, that pretty much nails it. Although GDFS does appear to do local caching when you do on-demand streaming, the performance would still be better since it doesn't need to finish downloading the file before it can open it. This is especially true when it comes to things like video.
Yeah, I'd forgotten about that, but yeah, I wasn't a fan of it at the time either — and it was especially bad since the Dropbox app of that era had numerous other problems like memory leaks and high CPU utilization that allowed its bad behaviour to have a far greater negative impact.
Yeah, it pretty much fell right into the "what could possibly go wrong?" category.
Does USB MIDI really still require kexts? Is MIDI not covered under the umbrella of HID devices? If so, I really wouldn’t be surprised to see Apple offer a new userland API for it in June/September.
FUSE (and MacFUSE) is already a thing, though it likely requires a kext. What I’m saying is that userland file system support has been a thing third parties have done for well over a decade. If third-parties could do it, Apple could easily have its own file system in userland implementation, which is totally something they should do even without this.
And this is why as a developer working with Windows sucks! I am forced into a Windows Workstation and WSL was a godsend except I can't upgrade to WSL2 until IT completes testing the newer updates. But hey that buggy sack of crap, Outlook gets to be updated all the time.
At a major performance cost, however. (It is fine for cloud storage though.)
As I said earlier in this thread, I'm relatively confident you'll continue to have that choice. You'll just need to turn off SIP. Apple uses kernel extensions for their own hardware, so you can always use that mechanism, once you disable the security check.
Last edited:
Surely if it requires a kext, then its not 100% class compliant - isn't that the whole point ?
Umm Steam has a Kext that adds support for most games. So maybe ask instead of assuming. In windows you can use drivers ("kexts") so things work regardless of support. Apple can advertise they are adding controller support all day but they are making it only work on an extremely small subset of programs.
My point is putty just works and doesn't cost anything. Where is putty for Mac? I guess Mac users just have money to blow.
Yes there is a hypervisor that I'm am relying on people to properly utilize. Docker works. Great. How about a decent hypervisor that's free to work with full Ubuntu and Windows ARM?
QEMU works and does what you want, although requires compiling. I have tried it and worked with it. I still prefer Parallels or VMWare.
Apple can work around using kext by having api to interface with in user land.
Yep, I'm wondering how this long-term affects pro audio drivers. I've got an RME Fireface UFX II, bought due to having some of the most bullet-proof lowest-latency drivers in the industry. I presume this would effect them?
You can switch it to Class Compliant mode but it's not nearly as good then (and don't get me started on how useless music production on my iPad Pro is... only marginally better then what you'd expect from a big iPod touch).
macOS continues to get dumber and more locked down and more fisher price while funny enough Windows is looking like a proper grown up desktop OS that keeps opening doors to more power tools with things like the Linux shell
At some point I just have to ignore M1 benchmarks and come to the realization that I’m spending a premium to get a locked down experience where they own everything about the software and hardware and don’t even let me repair my own hardware or plug in the peripherals I need without buying their dongles. Just terrible
At some point I just have to ignore M1 benchmarks and come to the realization that I’m spending a premium to get a locked down experience where they own everything about the software and hardware and don’t even let me repair my own hardware or plug in the peripherals I need without buying their dongles. Just terrible
What can kernel extensions provide that simply aren’t possible any other way?
And by that I don’t mean “list off apps that haven’t been re-engineered”.
I remember a few years back Spotify was causing kernel panics. The question there was why in the hell would a music streaming app need to be developed in such a risky way???