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: <20140320144456.GA20618@thunk.org>
Date:	Thu, 20 Mar 2014 10:44:56 -0400
From:	tytso@....edu
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Andreas Dilger <adilger@...ger.ca>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	"1o5g4r8o@...il.com" <1o5g4r8o@...il.com>,
	"738758@...s.debian.org" <738758@...s.debian.org>
Subject: Re: [PATCH] ext4: kill i_version support for Hurd-castrated file
 systems

On Thu, Mar 20, 2014 at 01:10:48AM -0700, Christoph Hellwig wrote:
> On Wed, Mar 19, 2014 at 11:27:57PM -0600, Andreas Dilger wrote:
> > Probably worthwhile to make those !EXT4_OS_HURD checks likely()?

Yes, and I was planning on optimizing the checks a bit more, but it
makes sense to do that in a separate patch, since this is not the only
place where we are making EXT4_OS_HURD checks.

> 
> Does it make sense to support the format at all given that it's unlikely
> to get any testing?

There are some crazy people still trying to make the Hurd a viable
file system.  There's even a Debian port for it.  :-) The problem is
that some of the folks who are still trying to make the Hurd real want
to use ext2 as an interchange format between Linux and Hurd, and
presumably that's how they ran across this particular bug.

While I think Hurd is a joke, and it's laughable that the primary file
system for the Hurd doesn't support journalling, or extents, delayed
allocation, or extended attributes[1], and it's hard for them get feature
parity because of the GPL v3 vs v2 compatibility problem, I don't mind
making minimal efforts to provide legacy support to the GNU Hurd.

[1] http://savannah.gnu.org/patch/?5126 (Patches available for the last
      seven years, not yet integrated)

In the long run, the right answer is that the Hurd should use an
extended attribute to store the translator information.  Indeed, this
has been discussed seven years ago[2].  But unfortunately, the
development temp for Hurd is a wee bit slower than for the Linux
kernel.  :-)

[2] http://savannah.gnu.org/task/?5503

					- 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ