linux-ext4 - Re: [PATCH 2/3] ext4: Context support

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]

Date:	Wed, 13 Jun 2012 16:00:33 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Arnd Bergmann <arnd.bergmann@...aro.org>
Cc:	Alex Lemberg <Alex.Lemberg@...disk.com>,
	HYOJIN JEONG <syr.jeong@...sung.com>,
	Saugata Das <saugata.das@...aro.org>,
	Artem Bityutskiy <dedekind1@...il.com>,
	Saugata Das <saugata.das@...ricsson.com>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mmc@...r.kernel.org, patches@...aro.org, venkat@...aro.org,
	"Luca Porzio (lporzio)" <lporzio@...ron.com>
Subject: Re: [PATCH 2/3] ext4: Context support

On Wed, Jun 13, 2012 at 07:44:35PM +0000, Arnd Bergmann wrote:
> 
> I think using the inode number is a reasonable fit. Using the
> inode number of the parent directory might be more appropriate
> but it breaks with hard links and cross-directory renames (we
> must not use the same LBA with conflicting context numbers,
> or flush the old context inbetween).

I think the inode number of the parent directory by itself is actually
*not* a good idea, because there are plenty of cases where files in
the same directory do not have the same life time.  For example,
consider your openoffice files in ~/Documents, for example.  Or worse,
the files in ~/Downloads written by your web browser.

It might be worth considering the hueristic of a series of files
written by a single process close together in time as belonging to a
single context.  That still might not be quite right in the case of a
git checkout for example, most of the time I think that hueristic
would be quite valid.

One thing that *would* be worth consider when trying to decide the
right granularity for a context would be the size of the erase block.
If the erase block is 2 megs, and we are writing a lot of 8 meg files,
a per-inode context granularity probably makes a lot of sense.

OTOH, if the erase block size is 8mb, and we are writing a whole bunch
of small files, we probably want to use a much more aggressive way of
aggregating relating blocks than just "inodes" that average in size of
say, 32k or 128k.  Getting this information may requiring leaning
rather hard on the eMMC manufacturers, since they (irrationally, in my
opinion) think this should be trade secret information.  :-(

	       	    	      	    	   - 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