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: <20250805162915.3kaqbxjbwfuj6u6w@P16.>
Date: Wed, 6 Aug 2025 00:29:15 +0800
From: Coly Li <colyli@...nel.org>
To: Zhou Jifeng <zhoujifeng@...inos.com.cn>
Cc: "kent.overstreet" <kent.overstreet@...ux.dev>,
	linux-bcache <linux-bcache@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bcache: enhancing the security of dirty data writeback

On Tue, Aug 05, 2025 at 05:37:44PM +0800, Zhou Jifeng wrote:
> On Tue, 5 Aug 2025 at 13:00, Coly Li <colyli@...nel.org> wrote:
> >
> > 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.
> > >
> >
> > [snipped]
> >
> >
> >
> > If before the cleared key inserted into the btree, there are new write
> > into overlapped LBA range of the cleared key and a dirty key inserted.
> > Then the cleared key is inserted and overwrites the dirty key, but the
> > dirty data on cache is not written back to backing device yet. How to
> > handle such situation?
> >
> 
> There are indeed some issues here. I have initially come up with a
> solution: Utilize the existing dc->writeback_keys mechanism for
> protection. The general processing flow is as follows:
> 1. In the write_dirty_finish() function, remove the operation of 
> updating bkey insertion, and delete the code bch_keybuf_del(&dc
> ->writeback_keys, w).
> 2. After executing the read_dirty(dc) code, perform flush, then
> insert the updated bkey, and finally remove the bkey from dc->
> writeback_keys. This process is equivalent to sending a flush
> every KEYBUF_NR bkeys are written back.
> 3. Support configurable KEYBUF_NR to indirectly control the
> frequency of flush.
> 
> Is this plan appropriate? Or are there any better ways to handle it?

No, I won't suggest this way. It sounds complicaed and changes the main
code flow too much in an implicit way, this should be avoided.

So it seems Kent's suggestion to flush backing device before committing
jset is the proper method I can see now.

Coly Li 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ