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 C522C1A08AF for ; Thu, 15 Jan 2026 17:10:27 +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=1768497029; cv=none; b=VJwE0wmu0YY/we7SRTe0tbL/y8+/rfk8H9DHRzRfTAStskz0iI1UWxGFDU/JXLU9MUJ2jEAKJ7JzOuxKJ1Bj5DEJZUDLFjLYahvOHgGndGhAV9U0ApcaWS6Kqbqne9U9m5wd9HVuMm16lI8n+seETD9LAenu/f1ofCWLKSB2+ww= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768497029; c=relaxed/simple; bh=L1JtxgPtFtKKc6y2TTTUNsyYEBRN/tX0bnKd0rBGjZ8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l/ESrYyjvgj+Hwpo4vEZiTGdsw28WM7IY6mWIPfFkGU86h22LPzvds3XMfawaf9abnmSRXR/v06MCnazFte3yme3680iBDFuACLUoYKzpC1PccGYfMXHBQ99T20kZq2SBchJ5xaOXeCu1uRdU7WsIdhdQbzJmi8tGINus652O7k= 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=SyaPhGpa; 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="SyaPhGpa" Received: from macsyma.thunk.org ([37.140.223.84]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 60FHACgx001540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jan 2026 12:10:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1768497016; bh=tia7F1V+yZWSVZsx8IjEn9IJb2Dvlx2/jJlMSpKCFRw=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=SyaPhGpazNStFD4d5vYYHZcCZTA8n4DrcNdBBTcOMTl6T3w1VhPLTGXI5IRDWwqii iOmVEI+hv/ST4K7kvuhV7VlLe4I5XtbTNfHQ2aZD4E64xQjH8YS0W08GLgyUAPVoeA A//SE7cddGg17V9NoQ4FgK7DwIy5B4YoYv3LaKdw3XoOWD2bzYhkyGwsakcP9nCfvy jzpjh6Sjopvq/ZHB7aXpVB1mKg1gkY3XU3OK2//D0AqUxoOuYs1wyQgm1VuoK7bLOP sXX0A/QyBjmkCv9Gx4ySWQ5Kl5sYrtYvvRe6E8vrnZeUYSjFJq88Xkf7eXv8O30KBe 0/XRCM3pnEZIg== Received: by macsyma.thunk.org (Postfix, from userid 15806) id DAA7154C9085; Thu, 15 Jan 2026 06:15:59 -0900 (AKST) Date: Thu, 15 Jan 2026 06:15:59 -0900 From: "Theodore Tso" To: Nathan Royce Cc: LKML , linux-mm@kvack.org, Andrew Morton , Hugh Dickins Subject: Re: TmpFs Incorporation Of FsCrypt? Message-ID: <20260115151559.GC19200@macsyma.local> References: <20260114204352.GA19200@macsyma.local> <20260115025920.GB19200@macsyma.local> 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 Thu, Jan 15, 2026 at 01:04:48AM -0600, Nathan Royce wrote: > This is the flip-flopping that I'm talking about for myself, because > if it worked the way I was hoping, that was the real draw for me. > I just figured the inode structure might/could also be session-based, > or a mix of global/session. The assumption is that these use cases (ChromeOS, Android) were ones where only one user would be using the device at a time. Adding per-session keying would have been extra complexity and a performance gain for not a whole lot of benefit. It's much simpler to just wipe the page cache and encryption keys when the user logs out, since the primary goal was preventing off-line ("evil maid") attacks and zero-day security vulnerabilities. > I was surprised when you mentioned the ability to reclaim space from > encrypted cache, and went to look into it, and came across > https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data/ > (even though it's ecryptfs). > It makes sense, and is a valid good reason for keeping fscrypt into > consideration over doing something like `homed` luks/btrfs loopback > file. fscrypt was designed as a solution to avoid the races that allowed programs like fsstress to quickly and reliably cause system deadlocks, as was the case with ecryptfs. In the case where you don't need the multi-user keying, the ability to share free space, and the ability for root to delete files when the key is not loaded to manage the shared free spacee, LUKS is the preferred solution because it encrypts the metadata. fscrypt leaks things like the timestamps and file size, and there are ways that an attacker can use this to figure out things about how the system is used. For example, consider what might happen if the Chinese government created a fake "free tibet" website, and embedded the web page a half-dozen hidden image files of specific sizes. Now when you cross the border, and they seize your laptop, if encrypted files of those specific sizes appear in your home directory, that might be a strong signal that you had visited that particular web site. Like many things, it's all about engineering tradeoffs, and there are reasons why some solutions might be a better fit than others. There is rarely a one-size-fits-all solution. Cheers, - Ted