linux-kernel - Re: [PATCH 0/1] Fuse Passthrough cache issues

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <315aef06-794d-478f-93a3-8a2da14ec18c@fastmail.fm>
Date: Wed, 3 Jul 2024 15:27:43 +0200
From: Bernd Schubert <bernd.schubert@...tmail.fm>
To: Daniel Rosenberg <drosen@...gle.com>, Miklos Szeredi <miklos@...redi.hu>,
 Amir Goldstein <amir73il@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 kernel-team@...roid.com
Subject: Re: [PATCH 0/1] Fuse Passthrough cache issues



On 7/3/24 03:02, Daniel Rosenberg wrote:
> I've been attempting to recreate Android's usage of Fuse Passthrough with the
> version now merged in the kernel, and I've run into a couple issues. The first
> one was pretty straightforward, and I've included a patch, although I'm not
> convinced that it should be conditional, and it may need to do more to ensure
> that the cache is up to date.
> 
> If your fuse daemon is running with writeback cache enabled, writes with
> passthrough files will cause problems. Fuse will invalidate attributes on
> write, but because it's in writeback cache mode, it will ignore the requested
> attributes when the daemon provides them. The kernel is the source of truth in
> this case, and should update the cached values during the passthrough write.

Could you explain why you want to have the combination passthrough and
writeback cache?

I think Amirs intention was to have passthrough and cache writes
conflicting, see fuse_file_passthrough_open() and
fuse_file_cached_io_open().

Also in <libfuse>/example/passthrough_hp.cc in sfs_init():

    /* Passthrough and writeback cache are conflicting modes */



With that I wonder if either fc->writeback_cache should be ignored when
a file is opened in passthrough mode, or if fuse_file_io_open() should
ignore FOPEN_PASSTHROUGH when fc->writeback_cache is set. Either of both
would result in the opposite of what you are trying to achieve - which
is why I think it is important to understand what is your actual goal.

I think idea for conflicting file cached and passthrough modes is that
the backing inode can already provide a cache - why another one for fuse?


> 
> The other issue I ran into is the restriction on opening a file in passthrough
> and non passthrough modes. In Android, one of our main usecases for passthrough
> is location metadata redaction. Apps without the location permission get back
> nulled out data when they read image metadata location. If an app has that
> permission, it can open the file in passthrough mode, but otherwise the daemon
> opens the file in normal fuse mode where it can do the redaction.
> 
> Currently in passthrough, this behavior is explicitly blocked. What's needed to
> allow this? The page caches can contain different data, but in this case that's
> a feature, not a bug. They could theoretically be backed by entirely different
> things, although that would be fairly confusing. I would think the main thing
> we'd need would be to invalidate areas of the cache when writing in passthrough
> mode to give the daemon the opportunity to react to what's there now, and also
> something in the other direction. Might make more sense as something the daemon
> can opt into.
> 
> Any thoughts on these issues? And does the proposed fix make sense to you?
> 
> 
> 
> Daniel Rosenberg (1):
>   fuse: Keep attributes consistent with Passthrough
> 
>  fs/fuse/passthrough.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> 
> base-commit: 73e931504f8e0d42978bfcda37b323dbbd1afc08


Thanks,
Bernd