LucidLink Kernel Extensions on macOS

Kiril Ivanov
Kiril Ivanov
  • Updated

In November of 2020, Apple announced a new generation of computer hardware based on an Apple-designed CPU chip. The introduction of this new kind of Apple CPU, known more commonly as the “M1” chip, represented a major departure for the company, as Apple had previously relied on CPUs designed and manufactured by Intel. The new M1 chips also ushered in some new requirements and new restrictions for Apple’s Mac-based operating system, as it relates to 3rd party software.

 

The LucidLink client software is designed to embed itself into the operating system at the file system level. This is necessary so it can present full-fledged random read/write file system semantics to all applications running on that machine, thus making it virtually indistinguishable from any local hard drive. This is how LucidLink can provide the infinite scalability of the cloud, without ever requiring users to change their established workflow. Emulating cloud storage as a conventional local hard drive without any noticeable impact to the user represents LucidLink’s fundamentally unique contribution to the industry. 

 

To achieve this, LucidLink installs a piece of software that runs in the kernel of the operating system. We do this for all supported operating systems, namely Windows, Linux and macOS.

 

On macOS, such software is known as a Kernel extension or “kext.” Kernel extensions have been in use for many years and are the mechanism through which third-party vendors augment the native macOS capabilities. LucidLink uses a forked version of a popular open-source project called macFUSE, formerly known as osxfuse (https://osxfuse.github.io/). FUSE, which stands for File System in Userspace, has had a long and well established history: it was originally created for Linux, and was later merged into the mainstream kernel tree in kernel 2.6.14 in 2005. It was also ported to other Unix-like operating systems including FreeBSD and OpenSolaris. In 2007, Google released an open source port of it for Mac OS X, and in 2011 it was forked to become osxfuse, later renamed to macFUSE. macFUSE is an exceptionally stable and reliable piece of software that has withstood the test of time. At LucidLink we have tens of thousands of customers that have been running macFUSE on their macOS systems for years, without ever reporting a single issue with it.

 

As a follow-on to the introduction of the Apple M1 CPU, Apple announced plans to deprecate macOS kernel extensions and replace them with a new mechanism called system extensions. The main premise behind this initiative was to improve the stability of macOS. Unlike regular applications, kernel extensions run in a privileged mode within the operating system, and as such could potentially introduce integrity and stability issues that affect the entire operating system. System extensions were designed to address this by offering user-level APIs for the most common use cases to third-party vendors. Since the system extensions run in user mode rather than in kernel mode, they have a limited impact on the overall system stability.

 

The problem with this approach however is that Apple currently does not, and possibly cannot provide full support for all possible kernel extensions that have been developed over the years. A case in point comes with macFUSE. While Apple does provide a system extension called FileProvier API, it only covers the common file synchronization use cases. LucidLink however does not synchronize (i.e. upload or download) entire files but rather streams the file segments that the application is requesting or updating in real-time. This is unique and fundamentally different from the standard file synchronization behavior, and the only way to accomplish this currently is through the deployment of macFUSE.

 

With the introduction of the Apple M1 (also known as Apple Silicon), Apple has made it more difficult for users to install and run kernel extensions as they are disabled by default on these newer platforms. There are 2 ways to enable them: explicitly adjust a setting in the macOS Recovery environment, or utilize Mobile Device Management (MDM) software like Jamf, which can enable kernel extensions across all devices within an organization. The former method relies on the user manually rebooting their machine into recovery mode, and adjusting the security policy to what Apple defines as “Reduced Security” and selecting “Allow user management of kernel extensions from identified developers”. In case MDM is used the kernel extension with Team ID "3T5GSNBU6W" should be allowed (bundle ID is  "com.lucidlink.lucidfs.filesystems.lucidfs").

 

As named, “Reduced security” is misleading, as it does not accurately describe what this kind of settings change actually represents. Thus, LucidLink would like its user base to know and understand these critical points:

  • Despite the unfortunate wording of “Reduced security,” kexts do not reduce a system’s security. If improperly developed, a kext could only affect system stability and reliability, but not the system’s security.
  • A given kext cannot be installed into the operating system unless it is approved and signed by Apple. It is not possible to run arbitrary code in the form of kext. 
  • As noted, LucidLink uses a kext called macFUSE, which has been battle-tested for over 15 years, and proven to be exceptionally reliable.
  • Enabling kernel extensions simply brings the system on par with any x86-based (i.e. Intel) Mac system.

 

LucidLink has been working directly with the Apple macOS storage team to find a solution to the above challenges. To date we have received the following assurances from their kernel team:

  1. Apple will only deprecate individual kexts that have an equivalent system extension API. Kexts that do not have equivalent APIs will not be deprecated. Apple has also stated that some kexts may never get equivalent APIs in the user space and therefore will continue to be allowed to run within the kernel.
  2. If and when Apple introduces a substitute system extension, third-party vendors will be given a full year to migrate before deprecating the specific kext.

 

In addition to the above, LucidLink is collaborating with Apple to define a potential future replacement for macFUSE in the form of a system extension.

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Article is closed for comments.