linux-kernel - Re: [RFC] apfs: thoughts on upstreaming an out-of-tree module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <d0be518b-3abf-497a-b342-ff862dd985a7@app.fastmail.com>
Date: Sat, 01 Mar 2025 00:04:27 +0100
From: "Sven Peter" <sven@...npeter.dev>
To: "Ethan Carter Edwards" <ethan@...ancedwards.com>,
 linux-kernel@...r.kernel.org
Cc: linux-fsdevel@...r.kernel.org, linux-staging@...ts.linux.dev,
 asahi@...ts.linux.dev
Subject: Re: [RFC] apfs: thoughts on upstreaming an out-of-tree module

Hi,


On Fri, Feb 28, 2025, at 02:53, Ethan Carter Edwards wrote:
> Lately, I have been thinking a lot about the lack of APFS support on
> Linux. I was wondering what I could do about that. APFS support is not 
> in-tree, but there is a proprietary module sold by Paragon software [0].
> Obviously, this could not be used in-tree. However, there is also an 
> open source driver that, from what I can tell, was once planned to be 
> upstreamed [1] with associated filesystem progs [2]. I think I would 
> base most of my work off of the existing FOSS tree.
>
> The biggest barrier I see currently is the driver's use of bufferheads.
> I realize that there has been a lot of work to move existing filesystem
> implementations to iomap/folios, and adding a filesystem that uses
> bufferheads would be antithetical to the purpose of that effort.
> Additionally, there is a lot of ifndefs/C preprocessor magic littered
> throughout the codebase that fixes functionality with various different
> versions of Linux. 
>
> The first step would be to move away from bufferheads and the
> versioning. I plan to start my work in the next few weeks, and hope to
> have a working driver to submit to staging by the end of June. From
> there, I will work to have it meet more kernel standards and hopefully
> move into fs/ by the end of the year.
>
> Before I started, I was wondering if anyone had any thoughts. I am open
> to feedback. If you think this is a bad idea, let me know. I am very
> passionate about the Asahi Linux project. I think this would be a good
> way to indirectly give back and contribute to the project. While I
> recognize that it is not one of Asahi's project goals (those being
> mostly hardware support), I am confident many users would find it
> helpful. I sure would.

Agreed, I think it would be helpful for many people (especially those
who still regularly dual boot between macOS and Linux) to have a working
APFS driver upstream.
This may also be useful once we fully bring up the Secure Enclave and need
to read/write to at least a single file on the xART partition which has
to be APFS because it's shared between all operating systems running on
a single machine.


It looks like there's still recent activity on that linux-apfs github
repository. Have you reached out to the people working on it to see
what their plans for upstreaming and/or future work are?



Best,


Sven