linux-ext4 - Re: [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup

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, 16 Jul 2008 13:18:24 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Jose R. Santos" <jrs@...ibm.com>
Cc:	Goswin von Brederlow <goswin-v-b@....de>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup

On Wed, Jul 16, 2008 at 11:02:42AM -0500, Jose R. Santos wrote:
> > PS: Should functions that chop off upper bits like that make sure they
> > are 0?
> 
> I think this is something that need to be cheched at fsck since having
> these be non-zero on a non-64-bit FS should be pointing to file system
> corruption.  Not sure if its something that need to be done every time
> we set a value on the lower bit only though.

Well, to quote Postel's law (also known as the robustness principle):
"Be conservative in what you do; be liberal in what you accept from
others."  

This is a generalization from what Jon Postel wrote in RFC 793: "TCP
implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others," but it applies here as well.  So yes, the library code should
clear the upper bits even if 64-bit feature flag is not set.  However,
we should not depend on the upper bits being zero if the 64-bit
feature flag is not set.

Does that make sense?

					- 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