From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754870AbcITViB (ORCPT <rfc822;w@1wt.eu>);
        Tue, 20 Sep 2016 17:38:01 -0400
Received: from zeniv.linux.org.uk ([195.92.253.2]:60922 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754782AbcITVhu (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 20 Sep 2016 17:37:50 -0400
Date: Tue, 20 Sep 2016 22:37:42 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
        Martin Schwidefsky <schwidefsky@de.ibm.com>,
        Jan Stancek <jstancek@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
        Greg Ungerer <gerg@uclinux.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fix fault_in_multipages_...() on architectures with
 no-op access_ok()
Message-ID: <20160920213742.GS2356@ZenIV.linux.org.uk>
References: <57E131E6.1090507@redhat.com>
 <20160920150657.GN2356@ZenIV.linux.org.uk>
 <570490469.234828.1474391501934.JavaMail.zimbra@redhat.com>
 <20160920190742.GP2356@ZenIV.linux.org.uk>
 <CA+55aFx-NuAZS9M0_UUwbMU91VnkG+gxLtqX-uWJQAYrh1Vq6w@mail.gmail.com>
 <20160920203821.GQ2356@ZenIV.linux.org.uk>
 <CA+55aFxZbjiHBjdwZ46eHYe12kkY_44y2cFAMAufzmv_nO+NEA@mail.gmail.com>
 <20160920210326.GR2356@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160920210326.GR2356@ZenIV.linux.org.uk>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Sep 20, 2016 at 10:03:26PM +0100, Al Viro wrote:

> The testcase here is uaddr = (void *)-1, len = (unsigned long)valid_addr + 2.
> If it tried to do __put_user(uaddr, 0) it would immediately fail, just as
> __copy_to_user(uaddr, len); the problem is, that call will only do
> __put_user(valid_addr, 0) and succeed.
> 
> Again, if get_user/put_user/copy_{to,from}_user() anywhere near ERR_PTR(...)
> would succeed, we'd get trouble without any wraparounds.  That page should
> be absent, and it really is.  In all cases, s390 included.  Wraparound is
> irrelevant here.  The reason why it got spotted was persistent failure of
> copy_{to,from}_user after successful fault-ins.

PS: s390 is far from the only such architecture - at least m68k, parisc
and sparc64 are the same way.

Sure, we can make all of them check for wraparounds, but what's the point,
when actual attempts to copy to/from such range will fail anyway and
for absolute majority of the calls the check will do nothing.  What's the
point?

Note that we need to compare uaddr and end in these loops anyway, so we
are not going to save anything there...