linux-kernel - Re: [RFC] writev() semantics with invalid iovec in the middle

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]

Message-ID: <CA+55aFykEyqgE4rOnJ2-GT3KM36P_c2gWqzQ39c-LBUpx0o4Hg@mail.gmail.com>
Date:   Fri, 16 Sep 2016 11:36:54 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Mike Marshall <hubcap@...ibond.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC] writev() semantics with invalid iovec in the middle

On Fri, Sep 16, 2016 at 6:25 AM, One Thousand Gnomes
<gnomes@...rguk.ukuu.org.uk> wrote:
>
> 1003.1 says
>
> "Each iovec entry specifies the base address and length of an area in
> memory from which data should be written. The writev() function shall
> always write a complete area before proceeding to the next."
>
> and I imagine that is what LTP is attempting to test.

Ahh. Yes. But as you note, the EFAULT case is undefined behavior, so
what that POSIX language is *really* about is presumably making sure
that readers of a file cannot see the "later" writes without seeing
the earlier ones.

So you cannot do some fancy threaded thing where you do different
iovec parts concurrently, because that could be seen by a reader (or
more likely mmap) as doing the writes out of order.

Or, as you mention, the disk-full case.

                   Linus