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]

Message-ID: <20120612123217.GB7288@thunk.org>
Date:	Tue, 12 Jun 2012 08:32:17 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Saugata Das <saugata.das@...aro.org>
Cc:	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,
	Arnd Bergmann <arnd.bergmann@...aro.org>
Subject: Re: [PATCH 2/3] ext4: Context support

On Tue, Jun 12, 2012 at 05:51:22PM +0530, Saugata Das wrote:
> > The proof-of-concept patches seem to use the inode number as a way of
> > trying to group related writes, but what about at a larger level than
> > that?  For example, if we install a RPM or deb package where all of
> > the files will likely be replaced together, should that be given the
> > same context?
> 
> In this patch, context is used at file level based on inode number.
> So, in the above example, multiple contexts will be used for the
> directory, file updates during RPM installation.

Yes --- I was trying to explore if we should try to do better than
that.  For example, it would probably be a good idea (at minimum) to
hash some kind of partition id into the inode number to form the
context id.  It's probably rare that a MMC card would be partitioned,
but it might be much more common for other flash devices.

I could also imagine schemes where via some fcntl, additional file
descriptors could be joined to the context of another file descriptor.
Or maybe we have a scheme whereby some high-level, abstract, context
id's could be generated, and assigned to a group of file descriptors.

A hueristic where all file creations that occur within close together
in time are considered to be related might work well for the package
installation case, but might break down in others.  Which is why I
asked the question of what is the downside if the hueristics screw up,
and occasionally group together files/blocks that aren't related with
respect to when they are deallocated (since that *is* what the flash
devices care about, right?)

						- 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