| 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
| ||
|
Message-ID: <20080716171824.GE2167@mit.edu> 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
Powered by blists - more mailing lists