linux-kernel - Re: [PATCH] fs: change sys_truncate/sys

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Sep 2009 09:31:15 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Heiko Carstens <heiko.carstens@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@....de>,
	Al Viro <viro@...iv.linux.org.uk>, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: change sys_truncate/sys_ftruncate length parameter
 type

Linus Torvalds wrote:
> 
> Look at sys_ftruncate() again. It doesn't convert it to signed long at 
> all. It converts it to 'loff_t' which is something different entirely.
> 
> Now, it may be that we _should_ convert it to 'long' like your patch does, 
> but this is definitely not a "no changes" patch as far as I can tell. It 
> limits ftruncate to 31 bits on 32-bit architectures, in ways it didn't use 
> to be limited.
> 
> [ Note the "small" logic and the interaction with O_LARGEFILE. On a 32-bit 
>   architecture, if you open with O_LARGEFILE, ftruncate() gets the full 
>   32-bit range, and that's the part your patch broke. ]
> 

I would argue that the current behavior is, if not incorrect (we define 
our own ABI after all) at least unwanted (we want our ABI to be as close 
as practical to the POSIX API.)

In particular, at the API level, both truncate() and ftruncate does take 
a signed (off_t) parameter, and the POSIX spec states:

        The ftruncate() function shall fail if:

        EINVAL The length argument was less than 0.

So yes, it's a change, but it seems to be one which probably should be done.

> In addition if hpa comes up with an automated way of generating
> compat wrappers it would generate wrong ones for these two cases.

I really mean to try to shake free some time and do that project.  I 
don't think it will happen before Kernel Summit, though :(

	-hpa

--
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/