<img src = "https://cdn.arstechnica.net/wp-content/uploads/2020/03/threatening-3-800×447.png" alt = "The proprietary file system provider Paragon Software appears to be coming up with one from Microsoft feel threatened by approved exFAT in the Linux 5.7 kernel Until a Microsoft approved exFAT is included in the Linux 5.7 kernel.
When the software and operating system giant Microsoft announced its support for the direct inclusion of the exFAT file system in the Linux kernel in August, not much was reported in the press. However, file system provider Paragon Software has clearly noted that the Microsoft-approved version of exFAT, largely written by Samsung, was integrated into the VFS for next repository this month, which in turn will be integrated into Linux 5.7 – and Paragon doesn't seem happy about it to be.
Yesterday Paragon released a press release about the European gateway modem provider Sagemcom, which is introducing its version of exFAT into an upcoming line of Linux-based routers. Unfortunately, the announcement was preceded by a stream of FUD (Fear, Uncertainty and Doubt) that wouldn't have been out of place on Steve Ballmer's letterhead in the 1990s.
dismantling of the FUD
Paragon described its arguments against open source software – which appeared directly in my inbox – as an "article (available for publication in any form) that explains why the open source model does not work in three cases Has."
All three cases offered by Paragon were at best strange examples.
Case One: Android
Let us first look at a few cases in which exFAT-like file systems were supported in Unix derivatives and how this works from an open source perspective.
The most substantiated case is Android, which creates a native Linux ext4FS container to run apps from FAT-formatted flash cards (3). This shows the inability (or unwillingness due to the realistic assessment of the effort required) of the software giant Google to implement a much simpler FAT in the Android kernel itself.
The footnote leads the reader to a long article by XDA developers that explains the long history of SD card file systems in the Android operating system. An extremely short summary: Android originally used the largely compatible VFAT implementation of the Windows FAT32 file system. This caused several problems – including security issues due to a lack of multi-user security metadata.
These problems led to Google replacing VFAT with a FUSE implementation (filesystem in userspace) developed by Samsung. This solved the security problems twice – not only that ACLs were now supported, the FUSE file system could even be deployed to individual users. Unfortunately, this caused performance problems – however practical FUSE may be, userspace file systems do not work as well as in-kernel file systems.
Up to now with us? Big. The final step in this story is that Google is replacing exFAT-FUSE with SDCardFS, another project developed by Samsung, which – confusingly – is not a file system at all. Instead, it is a kernel wrapper that forwards API calls to a child file system. SDCardFS replaces FUSE, not the file system, and enables emulated file systems to run in the kernel space.
If you're wondering where proprietary software comes from to save the day, the answer is simple: don't. This is a story of the largest smartphone operating system in the world that consistently and successfully uses open source software while improving performance and security.
What is not yet clear is whether Google will specifically use the new kernel exFAT landing in 5.7 in Android or will continue to use Samsung's SDCardFS file system wrapper. SDCardFS solved the performance problems of Android's auxiliary storage and may offer additional security benefits that simply using an ExFAT in the kernel would not offer.
Case two: MacOS
The other case is Mac OS – another Unix derivative that does not yet commercially support NTFS write mode – and only supports NTFS in read-only mode. That seems strange given the existence of NTFS-3G for Linux. You can enable write support – but there is no guarantee that NTFS volumes will not be damaged during the write process.
There are several problems using MacOS 'questionable NTFS support as a case against open source software. The first is that NTFS support for Apple doesn't seem to be a real priority in the first place. MacOS Classic had no NTFS support at all. The NTFS support available after Mac OS X 10.3 "Panther" was practically a giveaway – it was already available in FreeBSD-derived VFS (Virtual File System) and in the network stack.
Another problem with this comparison is that NTFS is a fully functional, completely modern file system with no missing parts. In contrast, exFAT – the file system on whose Linux kernel implementation Paragon FUD throws – is an extremely simple, lightweight file system that was developed for use in embedded devices.
The final nail in this particular coffin is that the open source NTFS implementation used by MacOS has not been approved by Microsoft. It is a reverse engineered workaround solution for a proprietary file system. Even worse, it's an implementation that was done at a time when Microsoft was actively trying to close the open source community – and it's not even the modern version.
As Paragon notes, NTFS-3G is the modern open source implementation of NTFS. NTFS-3G, a proprietary / licensed double-license GPL, does not suffer from potential write corruption problems – and is available on both MacOS and Linux.
Mac users who don't need the highest performance can install a free FUSE implementation of NTFS-3G with homebrew, while those who want native or near-native performance can purchase a lifetime license directly from Tuxera. Each $ 15 license includes unlimited free upgrades and installation on up to three PCs.
It is probably worth noting that, in addition to selling a proprietary implementation of exFAT, Paragon sells a proprietary implementation of NTFS for the Mac.
Case three: SMB
Another example outside of file systems is an open source SMB protocol implementation. Mac OS and the majority of printer manufacturers do not rely on an open source solution, as there are several commercial implementations of SMB when a commercial level of support is required.
It is unclear why Paragon thought this was a good argument against open source implementations of a file system. SMB (Server Message Block) is not a file system at all. It is a network communication protocol that was introduced with Microsoft Windows.
It is certainly true that many proprietary implementations of SMB exist – including one in direct partnership with Microsoft, made by Paragon rival and NTFS-3G provider Tuxera. However, this is another very strange flex to try against open source file system implementations.
Apart from the question of what SMB has to do with exFAT, we should note the extensive commercial use of Samba, the original gangster of open source SMB networking. In particular, Synology uses Samba for its network attached storage (NAS) servers, as well as Netgear and QNAP. Samba.org itself also lists top-class commercial providers, including American Megatrends, Hewlett-Packard, Veritas and VMWare.
Open Source is here to stay
We congratulate Paragon on signing their timely exFAT contract with Sagemcom. While there is good reason to believe that the Samsung-derived and Microsoft-approved exFAT implementation in Linux 5.7 will be secure, stable, and high-performing, it is not yet available – and not even in the upcoming Linux kernel, 5.6, We expect general availability to be achieved in late April or early May.
In the meantime, a company with a business need for design decisions – like Sagemcom – is likely to make the right decision to use a proprietary exFAT implementation with commercial support. Licensing costs are likely to be a small percentage of what the company earns in gross router sales, and the implementation of Paragon is a known value.
However, we suspect that the exFAT landscape will tilt significantly once Samsung's Microsoft-blessed version reaches the mainstream Linux kernel. Hopefully Paragon will now develop a more modern open source strategy while there is still time.