linux-ext4 - Re: Mentor for a GSoC application wanted (Online ext2/3 filesystem checker)

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:	Fri, 18 Apr 2008 21:29:52 -0400
From:	Theodore Tso <tytso@....EDU>
To:	Alexey Zaytsev <alexey.zaytsev@...il.com>
Cc:	linux-ext4@...r.kernel.org, linux-fsdev@...r.kernel.org,
	Rik van Riel <riel@...riel.com>
Subject: Re: Mentor for a GSoC application wanted (Online ext2/3 filesystem
	checker)

On Fri, Apr 18, 2008 at 06:20:14PM +0400, Alexey Zaytsev wrote:
> Hello, guys.
> 
> It seems like the Linux-fountation was not able to find a mentor for
> my project. If somebody is willing to mentor this project through the
> Google Summer of Code, please contact Rik and me now, as little
> time is left.
> 
> A link to the application:
> http://rom.etherboot.org/share/xl0/gsoc2008/application-linux-foundation.txt

Hi Alexey,

I really don't think your project is likely to be successful given the
3 month timeframe of a GSoC.  At least not without a mentor spending
vast amounts of time educating you about how things works within ext2
and e2fsck.  Even given some broad hints about problems that you need
to address, you still have not addressed how you will solve
fundamental race conditions resulting from trying to read the multiple
blocks scattered all over the disk which comprise allocation bitmap
blocks while allocations might be taking place, for example.

Your approach of monitoring writes to the buffer cache for metadata
writes is completely busted; suppose the kernel modifies block #12345
in the filesystem; how do you know what that means?  Could that be an
indirect block?  If so, to which inode does it belong?  If all you are
doing is monitoring metadata blocks, you would have no idea!  The fact
that it apparently didn't even occur to you that this might be a
show-stopping problem scares the heck out of me.  It leads me to
believe that this project is very likely to fail, and/or will require
vast amounts of time from the mentor.  Unfortunately, the former is
something that I just don't have this summer.

Regards,

						- 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