linux-ext4 - Re: 4.9 kernel ext4 extent magic found in file data block

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

Message-ID: <CAKwPUox3QBGpFhg-ghtYzeHtWKtwcWa=A7Z6d0kCj9Cpjy4uMw@mail.gmail.com>
Date:   Wed, 15 Aug 2018 10:14:45 +0800
From:   Kassey <kassey1216@...il.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Kees Cook <keescook@...omium.org>,
        Eric Biggers <ebiggers@...gle.com>, nborisov@...e.com,
        eguan@...hat.com, linux-ext4@...r.kernel.org, kassey@....com
Subject: Re: 4.9 kernel ext4 extent magic found in file data block

hi Ted:

thanks for the suggest. finally added O_SYNC to open solved the issue.
we are checking the storage setting.

Br
kassey


On Fri, Aug 3, 2018 at 11:09 PM, Theodore Y. Ts'o <tytso@....edu> wrote:
> On Fri, Aug 03, 2018 at 06:15:48PM +0800, Kassey wrote:
>> hi linux-ext4 team:
>>
>>     we got a easy reproduced issue that during OTA, the storage is  Samsung UFS.
>>     we will extract the updated file to DDR firstly(buffer_from_ddr)...
>>
>>     but we found some of the files is corrupted sometimes.
>>     we compared the success and failure found that below pattern f30a
>> EXT4_EXT_MAGIC
>>     were in the failure file data block.
>>
>>     which should be expected to in inode table extent info.
>>
>
> The way OTA (Over the air) update works is that it "patches" the file
> system.  Specifically, userspace (a program in the recovery partition)
> is directly updating the file system at the block level.
>
> The OTA data file is calculated by looking at the starting file system
> image, and the destination file system image, comparing the two, and
> then creating a "delta" file which is what is actually sent over the
> air.
>
> What you are seeing could be caused by:
>
> *) A bug in the program which generates the OTA file
>
> *) A bug in the program which uses the OTA file to update file systems
>
> *) The OTA file getting corrupted
>
> *) The starting file system image is different from what is expected;
>    that is, it is different from the starting file system image used
>    when generating the OTA file.
>
>>    do you have some debug suggest to check how a extent looks like
>> info write to a ext4 file data block ?
>
> A file data block can look like *anything*, including the header of
> extent data block.  For example, if you create a file system image,
> e.g:
>
>         mke2fs -t ext4 test.img 8M
>
> The file system that contains test.img will, by *definition* contain
> blocks that look like extent data blocks; in fact, they *are* extent
> data blocks, but not for the file system where test.img is stored, but
> in the test.img file system itself.
>
> Furthermore, the program which applies the OTA update has no idea
> whether a particular block it is updating is file data block.  It
> simply doesn't have that context.  The OTA update system is also not
> something which is maintained by the upstream ext4 developers (which
> is who you have contacted when you e-mailed linux-ext4@...r.kernel.org).
>
> So I'm afraid we can't help you behind giving you a general
> explanation of how OTA works (and this is only something I know
> because I've worked with the Android team).  I would check to see
> whether you are properly configuring and creating OTA updates, as well
> as checking whether Samsung made many local changes to the OTA update
> system.
>
> Best regards,
>
>                                         - Ted



-- 
Best regards
Kassey