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>] [day] [month] [year] [list]
Date:   Tue, 20 Mar 2018 08:49:13 +0800 (GMT+08:00)
From:   "Jidong Xiao" <0121167@...an.edu.cn>
To:     "Andreas Dilger" <adilger@...ger.ca>, linux-ext4@...r.kernel.org
Cc:     "Jidong Xiao" <jidong.xiao@...il.com>
Subject: Re: Re: Re: No data blocks at all in my ext4 journal



> -----Original Messages-----
> From:"Jidong Xiao" <jidong.xiao@...il.com>
> Sent Time:2018-03-20 08:26:30 (Tuesday)
> To:"Jidong Xiao" <0121167@...an.edu.cn>
> Cc:"Andreas Dilger" <adilger@...ger.ca>, linux-ext4@...r.kernel.org
> Subject:Re: Re: No data blocks at all in my ext4 journal
> 
> 
> 
> 
> 
> 
> On Mon, Mar 19, 2018 at 6:19 PM, Jidong Xiao <0121167@...an.edu.cn>wrote:
> 
> > 
> > > -----Original Messages-----
> > > From: "Andreas Dilger" <adilger@...ger.ca>
> > > Sent Time: 2018-03-20 07:46:23 (Tuesday)
> > > To: "Jidong Xiao" <0121167@...an.edu.cn>
> > > Cc: linux-ext4@...r.kernel.org
> > > Subject: Re: No data blocks at all in my ext4 journal
> > >
> > > On Mar 19, 2018, at 5:31 PM, Jidong Xiao <0121167@...an.edu.cn> wrote:
> > > >
> > > > Hi,
> > > >
> > > > When I use the dd command to examine the journal, it turns out every block starts with the jbd2 magic number, meaning they are either a superblock, a descriptor block, or a commit block, or a revoke block, but there is no data block.
> > > >
> > > > I manually and randomly tried like 50 blocks after that superblock, but I haven't seen any data blocks.
> > > >
> > > > The kernel version I am using is, 4.14. Is this a serious bug or am I doing something wrong? Anyone has any suggestions, or tell me how to find the data blocks in my journal, or are they actually missing from the journal? By data blocks, I mean metadata, as my system is using the default mode, i.e., the ordered journal mode, only metadata will be logged.
> > > >
> > > > Thanks. Let me know if more information is needed.
> > >
> > > You can decode the journal structure using debugfs, and it will show you the
> > > blocks more easily:
> > >
> > > # debugfs -c -R "logdump -a" /dev/vg_mookie/lv_root
> > > debugfs 1.42.13.wc5 (15-Apr-2016)
> > > Journal starts at block 13970, transaction 1103250
> > > Found expected sequence 1103250, type 1 (descriptor block) at block 13970
> > > Dumping descriptor block, sequence 1103250, at block 13970:
> > >   FS block 12058640 logged at journal block 13971 (flags 0x0)
> > >   FS block 3 logged at journal block 13972 (flags 0x2)
> > >   FS block 12059015 logged at journal block 13973 (flags 0x2)
> > >   FS block 12058703 logged at journal block 13974 (flags 0x2)
> > >   FS block 12066941 logged at journal block 13975 (flags 0x2)
> > >   FS block 12058641 logged at journal block 13976 (flags 0x2)
> > >   FS block 12059178 logged at journal block 13977 (flags 0x2)
> > >   FS block 0 logged at journal block 13978 (flags 0xa)
> > > Found expected sequence 1103250, type 2 (commit block) at block 13979
> > >
> > > Cheers, Andreas
> > >
> > >
> > 
> > Hi, Andreas,
> > 
> > Thanks for your kindly response.
> > 
> > I tried the TSK tool and debugfs, the results are the same, there is no data/metadata block in my journal. Every block is either a superblock, or a descriptor block, or a commit block. For example, using debugfs with the command you provided, I got this:
> > 
> > [lab7]$ sudo debugfs -c -R "logdump -a" /dev/sda3
> > Journal starts at block 7757, transaction 8305398
> > Found expected sequence 8305398, type 1 (descriptor block) at block 7757
> > Dumping descriptor block, sequence 8305398, at block 7757:
> > FS block 36700177 logged at journal block 7758 (flags 0x0)
> > FS block 9 logged at journal block 7759 (flags 0x2)
> > FS block 36700889 logged at journal block 7760 (flags 0x2)
> > FS block 36700501 logged at journal block 7761 (flags 0x2)
> > FS block 36709095 logged at journal block 7762 (flags 0x2)
> > FS block 36700161 logged at journal block 7763 (flags 0x2)
> > FS block 36700907 logged at journal block 7764 (flags 0x2)
> > FS block 0 logged at journal block 7765 (flags 0xa)
> > Found expected sequence 8305398, type 2 (commit block) at block 7766
> > [REMOVED]
> > 
> > And my journal superblock is at block 52461568, so journal block 7760 is file system block (52461568+7760)=52469328. Now I use dd command to examine 52469328, and I see this:
> > 
> > [lab7]$ sudo dd if=/dev/sda3 bs=4096 skip=52469328 | xxd | more
> > 00000000: c03b 3998 0000 0002 007e a8cd 0000 0000  .;9......~......
> > 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 00000030: 0000 0000 5aaf 8011 16ca 442c 0000 0000  ....Z.....D,....
> > 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 
> > As you can see, debugfs says this is a journal metadata block records a file system block 36700889, yet the dd command says this is a journal commit block. I tried many journal blocks, and I don't see any metadata/data blocks in my journal. For example, these are the neighbor journal blocks:
> > 
> > [lab7]$ sudo dd if=/dev/sda3 bs=4096 skip=52469326 | xxd | more
> > 00000000: c03b 3998 0000 0002 007e 93e0 0000 0000  .;9......~......
> > 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 00000030: 0000 0000 5aae 8541 28b6 9e9c 0000 0000  ....Z..A(.......
> > 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 
> > [lab7]$ sudo dd if=/dev/sda3 bs=4096 skip=52469327 | xxd | more
> > [sudo] password for jxiao:
> > 00000000: c03b 3998 0000 0001 007e 93e1 0230 0156  .;9......~...0.V
> > 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 00000020: 0000 0000 0000 0000 0000 0002 0260 0002  .............`..
> > 00000030: 0000 0002 0000 000a 0000 000a 0000 0000  ................
> > 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 
> > [lab7]$ sudo dd if=/dev/sda3 bs=4096 skip=52469329 | xxd | more
> > 00000000: c03b 3998 0000 0001 007e a8ce 0230 0156  .;9......~...0.V
> > 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 00000020: 0000 0000 0258 000d 0000 0002 0000 000a  .....X..........
> > 00000030: 0000 000a 0000 0000 0000 0000 0000 0000  ................
> > 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 
> > [lab7]$ sudo dd if=/dev/sda3 bs=4096 skip=52469330 | xxd | more
> > 00000000: c03b 3998 0000 0001 007e 5358 0230 0156  .;9......~SX.0.V
> > 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 00000020: 0000 0000 0000 0000 0000 0002 0230 0004  .............0..
> > 00000030: 0000 0002 0000 0009 0000 000a 0000 0000  ................
> > 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> > 
> > -Jidong
> > 
> > 
> 
> Hi, Andreas,
> 
> 
> Also, can you examine the contents of your journal block 13971, and see if it's a real data/metadata block or it's like mine, i.e., a descriptor block, commit block. Thanks.
> 
> 
> -Jidong
> 

And I also tried this on a different computer, which is running kernel version 4.4; So this means, I am having this same problem on both kernel version 4.4 and kernel version 4.14; but I am not sure if this is a serious bug or I did something wrong. My understanding is, The debugfs or the TSK tools tell us which journal blocks are used for recording which regular blocks, but they didn't verify this statement, instead they just collected the information from the descriptor blocks.

In addition, I can't find any evidence on the Internet showing someone has actually examined the ext4 journal data, so I am not sure if this problem is commonly existing.

-Jidong




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ