linux-kernel - Re: TmpFs Incorporation Of FsCrypt?

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: <20260115151559.GC19200@macsyma.local>
Date: Thu, 15 Jan 2026 06:15:59 -0900
From: "Theodore Tso" <tytso@....edu>
To: Nathan Royce <nroycea+kernel@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>
Subject: Re: TmpFs Incorporation Of FsCrypt?

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