linux-kernel - Re: [PATCH 0/5] Fix a minor POSIX conformance problem

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: <Y902c9MRvXghKJMy@casper.infradead.org>
Date:   Fri, 3 Feb 2023 16:29:39 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     David Laight <David.Laight@...lab.com>
Cc:     Andreas Dilger <adilger@...ger.ca>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-afs@...ts.infradead.org" <linux-afs@...ts.infradead.org>,
        "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Hugh Dickins <hughd@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "fstests@...r.kernel.org" <fstests@...r.kernel.org>
Subject: Re: [PATCH 0/5] Fix a minor POSIX conformance problem

On Fri, Feb 03, 2023 at 04:23:32PM +0000, David Laight wrote:
> From: Matthew Wilcox
> > "The system shall always zero-fill any partial page at the end of an
> > object. Further, the system shall never write out any modified portions
> > of the last page of an object which are beyond its end. References
> > within the address range starting at pa and continuing for len bytes to
> > whole pages following the end of an object shall result in delivery of
> > a SIGBUS signal."
> > 
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
> 
> It also says (down at the bottom of the rational):
> 
> "The mmap() function can be used to map a region of memory that is larger
> than the current size of the object. Memory access within the mapping but
> beyond the current end of the underlying objects may result in SIGBUS
> signals being sent to the process. The reason for this is that the size
> of the object can be manipulated by other processes and can change at any
> moment. The implementation should tell the application that a memory
> reference is outside the object where this can be detected; otherwise,
> written data may be lost and read data may not reflect actual data in the
> object."
> 
> There are a lot of 'may' in that sentence.
> Note that it only says that 'data written beyond the current eof may be
> lost'.
> I think that could be taken to take precedence over the zeroing clause
> in ftruncate().

How can the _rationale_ (explicitly labelled as informative) for one
function take precedence over the requirements for another function?
This is nonsense.

> I'd bet a lot of beer that the original SYSV implementation (on with the
> description is based) didn't zero the page buffer when ftruncate()
> increased the file size.
> Whether anything (important) actually relies on that is an interesting
> question!
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>