linux-kernel - Re: [PATCH v2] vfs: prevent copy_file

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, 17 Feb 2021 17:50:35 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Steve French <smfrench@...il.com>,
        Anna Schumaker <anna.schumaker@...app.com>,
        Luis Henriques <lhenriques@...e.de>,
        Trond Myklebust <trondmy@...merspace.com>,
        "samba-technical@...ts.samba.org" <samba-technical@...ts.samba.org>,
        "drinkcat@...omium.org" <drinkcat@...omium.org>,
        "iant@...gle.com" <iant@...gle.com>,
        "linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
        "darrick.wong@...cle.com" <darrick.wong@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jlayton@...nel.org" <jlayton@...nel.org>,
        "llozano@...omium.org" <llozano@...omium.org>,
        "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "miklos@...redi.hu" <miklos@...redi.hu>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "dchinner@...hat.com" <dchinner@...hat.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "sfrench@...ba.org" <sfrench@...ba.org>,
        "ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>
Subject: Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

On Feb 17, 2021, at 1:08 AM, Amir Goldstein <amir73il@...il.com> wrote:
> 
> You are missing my point.
> Never mind which server. The server does not *need* to rely on
> vfs_copy_file_range() to copy files from XFS to ext4.
> The server is very capable of implementing the fallback generic copy
> in case source/target fs do not support native {copy,remap}_file_range().
> 
> w.r.t semantics of copy_file_range() syscall vs. the fallback to userespace
> 'cp' tool (check source file size before copy or not), please note that the
> semantics of CIFS_IOC_COPYCHUNK_FILE are that of the former:
> 
>        rc = cifs_file_copychunk_range(xid, src_file.file, 0, dst_file, 0,
>                                        src_inode->i_size, 0);
> 
> It will copy zero bytes if advertised source file size if zero.
> 
> NFS server side copy semantics are currently de-facto the same
> because both the client and the server will have to pass through this
> line in vfs_copy_file_range():
> 
>        if (len == 0)
>                return 0;
> 
> IMO, and this opinion was voiced by several other filesystem developers,
> the shortend copy semantics are the correct semantics for copy_file_range()
> syscall as well as for vfs_copy_file_range() for internal kernel users.
> 
> I guess what this means is that if the 'cp' tool ever tries an opportunistic
> copy_file_range() syscall (e.g. --cfr=auto), it may result in zero size copy.

Having a syscall that does the "wrong thing" when called on two files
doesn't make sense.  Expecting userspace to check whether source/target
files supports CFR is also not practical.  This is trivial for the
kernel to determine and return -EOPNOTSUPP to the caller if the source
file (procfs/sysfs/etc) does not work with CFR properly.

Applications must already handle -EOPNOTSUPP with a fallback, but
expecting all applications that may call copy_file_range() to be
properly coded to handle corner cases is just asking for trouble.
That is doubly true given that an existing widely-used tool like
cp and mv are using this syscall if it is available in the kernel.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)