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

["Sven Peter" <sven@svenpeter.dev>]

Hi,

On Thu, Mar 6, 2025, at 19:04, Theodore Ts'o wrote:
> On Wed, Mar 05, 2025 at 07:23:55AM +0000, Aditya Garg wrote:
>> 
>> This driver tbh will not ‘really’ be helpful as far as T2 Macs are
>> concerned.
>> 
>> On these Macs, the T2 Security Chip encrypts all the APFS partitions
>> on the internal SSD, and the key is in the T2 Chip. Even proprietary
>> APFS drivers cannot read these partitions.  I dunno how it works in
>> Apple Silicon Macs.
>
> How this workings on Apple Silicon Macs is described in this article:
>
>    https://eclecticlight.co/2022/04/23/explainer-filevault/
>
> It appears such a driver will also be useful if there are external
> SSD's using APFS.  (Although I suspect many external SSD's would end
> up using some other file system that might be more portable like VFS.)
>
> In terms of making it work with the internal SSD, it sounds like Linux
> would need to talk to the secure enclave on the T2 Security Chip and
> convince it to upload the encryption key into the hardware in-line
> encryption engine.  I don't know if presenting the user's password is
> sufficient, or if there is a requirement that the OS prove that it is
> "approved" software that was loaded via a certified boot chain, which
> various secure enclaves (such as TPM) are wont to do.

At least on Apple Silicon all you need is the user password (and a working
Secure Enclave driver and a way to forward entangled keys from the Secure
Enclave to the NVMe co-processor). It's still possible to unlock the
encryption keys inside the Secure Enclave when booting into a secondary
macOS installation with all security features disabled (and with a
modified kernel). I'd assume the same applies to T2/x86 machines since
the T2 is an ancestor of the M-series Apple Silicon SoCs.

The only limitation that I'm aware of is that access to DRM keys
(HDCP, FairPlay for video streaming, etc.) is only allowed via a
certified boot chain.


Sven