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: <etlu4r6gxbe2jc3eemj3n4slg6xraxtxxydvxvmhv77xv42uss@7aw3yxbdgrdl>
Date: Thu, 31 Jul 2025 11:49:14 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Zhou Jifeng <zhoujifeng@...inos.com.cn>
Cc: colyli@...nel.org, linux-bcache@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bcache: enhancing the security of dirty data writeback

On Thu, Jul 31, 2025 at 02:21:40PM +0800, Zhou Jifeng wrote:
> There is a potential data consistency risk in bcache's writeback mode:when
> the application calls fsync, bcache returns success after completing the
> log write, persisting the cache disk data, and persisting the HDD internal
> cache. However, at this point, the actual application data may still be in
> a dirty state and remain stuck in the cache disk. when these data are
> subsequently written back to the HDD asynchronously through REQ_OP_WRITE,
> there is no forced refresh mechanism to ensure physical placement on the
> disk, and there may be no power-off protection measures, which poses a risk
> of data loss. This mechanism may cause the application to misjudge that the
> data has been persisted, which is different from the actual storage state,
> and also violates the semantic agreement that fsync should ensure data
> persistence.

So, the way you start out describing the patch, it sounds like you're
addressing some sort of bug in REQ_OP_FLUSH handling, but it looks like
what you're actually doing is adding a mode where flushes also flush
bcache?

This doesn't sound like a bugfix, this sounds like a completely new
mode - we'd need an explanation of the use case you're aiming for.

The model for bcache has always been that since the cache is persistent,
when you're in writeback mode there are no fsync/REQ_OP_FLUSH
considerations for dirty data; once we've properly persisted (and
flushed) that data we're good.

If you want a mode where you can run in writeback mode, but obey flushes
so that it's still safe to lose or yank the cache device - is that what
you're after?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ