linux-ext4 - Re: flashing large eMMC partitions with ext4

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jul 2011 21:21:39 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Round Robinjp <roundrobinjp@...oo.co.jp>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: flashing large eMMC partitions with ext4

On Wed, Jul 27, 2011 at 02:38:19AM +0900, Round Robinjp wrote:
> 
> I see.
> The flash will then contain _random_ data in the non-used blocks.
> That is not a problem, right?

Nope.  So long as the previously written (random) data on the card
doesn't contain anything security sensitive.

So for example, if someone used a microSD card to transfer credit card
numbers from their e-commerce website to their credit card processor,
and then afterwards, deciding they didn't need the card any more, and
dropped it into a bin at the production line where it got flashed and
put into a cell phone that was then shipped to Best Buy, then the
non-used blocks wouldn't get written and credit card numbers might get
exposed.  But that's probably only something that folks who designed
the security systems at Sony would do, so there's nothing to worry
about.  :-)

> One more thing.
> Although I have very small amount of files in my 4G image,
> I see that the image has almost no zero-filled blocks.
> Is that normal for ext4?

It depends on how you created the image.

> Can zerofree.c recognize them as non-used blocks?

Yes, it uses the block allocation bitmaps to understand what is used
and non-used.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html