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] [day] [month] [year] [list]
Date:	Tue, 19 Aug 2008 17:43:39 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Theodore Tso <tytso@....edu>,
	Christoph Hellwig <hch@...radead.org>,
	Eric Paris <eparis@...hat.com>, tvrtko.ursulin@...hos.com,
	alan@...rguk.ukuu.org.uk, andi@...stfloor.org,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	malware-list-bounces@...sg.printk.net, peterz@...radead.org,
	viro@...IV.linux.org.uk
Subject: Re: [malware-list] TALPA - a threat model?  well sorta.

On Thu, Aug 14, 2008 at 07:34:30PM -0400, Theodore Tso wrote:
> On Thu, Aug 14, 2008 at 05:21:09PM -0400, J. Bruce Fields wrote:
> > > I have not yet seen code actually using it at all, neither in mainline
> > > nor on one of the many nfs development lists.
> > 
> > Oops, I'd love to, and it should be very easy.  How do I find out if
> > i_version is supported on a given superblock?
> 
> We don't have a way of exporting this fact at the moment.  I assume
> the best way would be to add a flag in struct super.
> 
> > There's nothing particularly "advanced" about this, by the way--this is
> > a very minor variation on the caching model that nfs has always had, and
> > our nfsv4 server is currently pretty broken without it.
> 
> Well, if you're willing to try it out, as I've mentioned on my
> blog[1][2], ext4 is working pretty well on my laptop --- I'm running
> it as my primary filesystem.  There are a few problems with ext3
> filesystems converted to use ext4, as opposed to starting afresh via
> "mke2fs -t ext4dev /dev/hdXX" that we've just found in the past week
> (and fixed within a day or two, although they haven't been pushed to
> Linus yet), but overall, it's been pretty stable.
>
> So this would be a good time for someone who is familiar wiht NFSv4 to
> try it out and let us know if the i_version support is as you would
> like in ext4 --- we're in the bugfixing/stablization phase right now,
> so this would be an ideal time to get that feedback.  For more
> information, on how to get started, please see:
> 
> http://ext4.wiki.kernel.org/index.php/Ext4_Howto
> 
> for instructions, and mount the filesystem with the "-o i_version"
> mount option.

Neato, thanks.  I set up a toy ext4 filesystem (just a 512 meg sparse
file loopback mounted) on one of my test machines--so I just need to
add the superblock flag and a bit of nfsd code and then I should be able
to try it out.

> > Actually, it's pretty broken even on nfsv2/v3 for filesystems with poor
> > time resolution.
> 
> And that's fixed in ext4 as well....

That's an improvement, yes.  Of course the time is still updated only
every jiffy, so there's still a race:

				file updated
	client checks ctime
				file updated again within a jiffy
	client checks ctime again, concludes file hasn't changed.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ