linux-kernel - Re: [RFC, PATCH 6/6] ext3: do not write to the disk when mounting a dirty read-only filesystem

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: <20080312105351.GC3090@duck.suse.cz>
Date:	Wed, 12 Mar 2008 11:53:51 +0100
From:	Jan Kara <jack@...e.cz>
To:	Duane Griffin <duaneg@...da.com>
Cc:	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org, Theodore Tso <tytso@....edu>,
	sct@...hat.com, akpm@...ux-foundation.org
Subject: Re: [RFC, PATCH 6/6] ext3: do not write to the disk when mounting
	a dirty read-only filesystem

On Wed 12-03-08 02:42:46, Duane Griffin wrote:
> On Tue, Mar 11, 2008 at 04:11:23PM +0100, Jan Kara wrote:
> >   Actually, this is nastier than it looks - currently fs, asks
> > ext3_sb_getblk() for block 'a' and it gets buffer head with b_blocknr == 'b'
> > instead.
> 
> Note that it will be a different device as well, in the case of an
> external journal.
> 
> > So when remounting you'd have to rewrite these buffers with
> > original block numbers which is not really possible. So I think
> > remapping will have to be solved differently, like providing buffer
> > head with correct b_blocknr but taking care when reading data to it and
> > reading them from elsewhere. Actually, this has to be done anyway
> > because JBD escapes data in the journal and you have to do unescaping
> > when reading data...
> 
> Hmm, I'll think about this and try to get something working. As a quick
> proof-of-concept hack, getting both buffers then overwriting the fs
> block's data with the unescaped journal data should do the trick, right?
  Yes, it should, but you should take care for users that do things like:

  getblk(a)
  ll_rw_block(READ, a)

  or even

  getblk(a)
  submit_bh(a)

  I'm not sure if there are any in ext3/ext4 but it definitely needs
checking.

									Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/