From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 34D7F246782 for ; Wed, 14 Jan 2026 20:44:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768423456; cv=none; b=GIpuyVwEUs5g/JRLxyhHTTrFZB/nKYCk40fUI5EWz8+BdGnNmHMy6chqqtEtxJpPohxJBnUgngkEMKlKSLbrggITftwJ48Adld2uCpd3iqY2YtSiRqRDkf81MnDs48z9SngU07j0F0q9ftFQyjGNsOwBpxA6C8SGaaShvbAfYfo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768423456; c=relaxed/simple; bh=aue7NhnoLLq9LXb2SLFB/aPA1I3VYMWua93KYWpPA2g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HtCjzbrJjCnsrybjEyK6SQXx+MlnzPAG+ceSAZx2HA0chi5GD3oZYntJhQFyo2qfQXqekYYoO5tXu10OSru/xjNcr2ISMATszLqWgTx5Ffrj9cNCIC5rl4KLBR+c/4gzSwwlSvOhQBcrgJ9sOpwgmTmXghw7LCpt7HMNDxG2+6M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=eIt1oh6C; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="eIt1oh6C" Received: from macsyma.thunk.org ([136.144.33.86]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 60EKhrPJ027987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jan 2026 15:43:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1768423437; bh=woowc8iyRdlq7O6uDbNaE+SJXZ6TMqKXI61xMqfH4l8=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=eIt1oh6CTSbuCFH2Aa+tDH5O6d7ert5PTo8L5MznoWdJurx3wVcQGHbhxt3hVCKcD fFpIQ8m+pnK2HwS059mGDkfqX+o3C8AJW7v93iyuuo2dSOiGgRUYbY3SfnlnyaODTR RYBYCQBUrYJQsD06OcVW16PXm29QNwcAGIQUHQaglDA1x2h3C8xbkDIFEyffk/WzNW Kx7qS2POn7rXcDqdy6YcTblw6ezhNTnfQNYdu3eTX/h/AGowNy4BwrBE9NO/IDzhfC 2lHVZGFLCbjTpIMAGWgxQVAYcICyVi3DFs70U/R2N7jBTSBfocy/Jp8qRNFWZXkZHl e2VOx4tr/gA+Q== Received: by macsyma.thunk.org (Postfix, from userid 15806) id C1B6654AF834; Wed, 14 Jan 2026 12:43:52 -0800 (PST) Date: Wed, 14 Jan 2026 12:43:52 -0800 From: "Theodore Tso" To: Nathan Royce Cc: LKML , linux-mm@kvack.org, Andrew Morton , Hugh Dickins Subject: Re: TmpFs Incorporation Of FsCrypt? Message-ID: <20260114204352.GA19200@macsyma.local> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Jan 14, 2026 at 01:03:20AM -0600, Nathan Royce wrote: > But I also saw: `The source files are located on an in-memory filesystem > such as tmpfs.` in the main README, which makes me wonder if there is > intent/plan to bring fscrypt to tmpfs. > > I'm kind of thinking a use case of having keys and/or a password manager > database on external/encrypted storage, that gets transferred to some > random path in `/run/user/<#>` (tmpfs) on login where it is encrypted as > well (then the storage is unmounted/locked/removed), and the respective > program that uses the file(s) would point to a freshly generated config > that points to the random location. I'm not aware of anyone considering adding fscrypt to tmpfs. One reason why it might not make sense is that the primary value that fscrypt add is encryption at rest. For example, if you are using fscrypt to protect user files on a mobile phone, the file system level encryption protects the data from being accessible immediately after the phone is rebooted or power cycled. Many of the attacks which require direct access to the flash storage, or attempts to replace the kernel with one special "enhancements" courtesy of the NSA, KGB, Mossad, or MSS. However, if there is a zero day vulnerability which allows the attacker to compromise the currently running kernel without requiring a reboot, and while the encryption keys are in memory because the user is logged in --- fscrypt will likely not provide much protection. That's because if the keys are loaded, and the decrypted file contents are in the page cache, the only thing that prevents the attacker from gaining access to the file contents is the Unix permissions, and the system's discretionary access controls are very likely going to be compromised if the kernel has been compromised. This is why fscrypt for tmpfs might not be that useful. Tmpfs is not applicable for storage at rest. So when you copy the encrypted files from the persistent storage to the tmpfs, if you use fscrypt with tmpfs, the only way it would add value is if you want to remove the encryption keys from memory, without actually deleting the files from tmpfs. Otherwise, why not just zero the files and deleting the files from tmpfs, and when the user logs back in, just copy the files from the persistent storage into tmpfs? Cheers, - Ted