Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp2742101ybb; Sat, 30 Mar 2019 12:36:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqyObrOf75LJpLBUCPgvcIhgjfXHfec5647cinZCjNvUJTIUofThijkoW/RKQvtdHH7KXHTn X-Received: by 2002:a63:5466:: with SMTP id e38mr25571139pgm.340.1553974595367; Sat, 30 Mar 2019 12:36:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553974595; cv=none; d=google.com; s=arc-20160816; b=xL0DjKSUgk95WEF0doEgN+XjbWBucYLsZiN/7ewpRLBNmxXDrlVz/mG4RHqymxTFOU 7UeMMbPQh4x/8GbUIE7bRJnkafeJ3QXQdB9aKncMm7us2FqBCii1Fp9NFowkjPDdnzBw bhlnN/+rM6EjTVxxd6uXGs7DZPY4eJwM+u2ZXsW+NFyuF+A2VbevqDkHfF7wObtTw7ym nmsR49sYiFmkzGFnInsHki85STwZhfPm0cBwK6bCTqFRHzYoDj4B/XuD84++d3fnPIAL d7g4iXKJ7p/CQajrI6EAL7Sy91sf5iJL6EMz3lrpWaXzRMNXoaiI11b67g1d4y99AGlD rxHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature; bh=Zo5S2XHHlJ7v/ahXnx449DOOZlBX+45EYNQRCm8N/rg=; b=yNWFirUMzVYHLwZYDMtwtoDRz6PjB9b7RunX7LRY+AqVX4IcfKcVnyFr2rZ3IbRLAi nGTmJfOJRM4387BGa2eZe3RMJjnIvqCYzuFIvXGzC4B59QlTNYNTZbSq2Q2WWbuMnDLu 4gRAYPuXAxuTVOG7GR43SQeYboaxdSUTkKU774Onneg00HhXg0d8q+0ySXnxofkP/Xu3 9+7/0Cr+bXQWK//X/03l0Ds0ZxmDokpXRWB4IP1hYHVQvH2GUaoYYN7jnBNho4NfEHSa nsQ7mRXCVXFQ4sh56TykO0H6nWmol4JDrFRjjWtRUY29WUsdDflFfJ6kryCdpsOZEEAe CJlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=mONh6IYP; dkim=pass header.i=@codeaurora.org header.s=default header.b=JPDs4ghL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h127si5383607pfb.213.2019.03.30.12.36.18; Sat, 30 Mar 2019 12:36:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=mONh6IYP; dkim=pass header.i=@codeaurora.org header.s=default header.b=JPDs4ghL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730887AbfC3Tfm (ORCPT + 99 others); Sat, 30 Mar 2019 15:35:42 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:37270 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730542AbfC3Tfm (ORCPT ); Sat, 30 Mar 2019 15:35:42 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 9187160907; Sat, 30 Mar 2019 19:35:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1553974540; bh=p4AR5hXP47ztUsFViQu0vH0Il83mBoYgsSHmwZpUHxE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mONh6IYPBj9Soenom0p/3gJ9zgJlOSZNVT11qrGUTwgXR2E1KBOI6mDjPoo2wUUMv b+QgW90PIvX7OmBcNpuywpXKJWVtTyRn7KOheBbhfdxQriNskh/U4S1kphJvoKuTFz nujEL3wuk7LdWRJ/Z8g9DYIyoqxQp0+HpHtfXPcY= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.0 Received: from [10.79.169.97] (blr-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.18.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mojha@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 51D02602FC; Sat, 30 Mar 2019 19:35:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1553974539; bh=p4AR5hXP47ztUsFViQu0vH0Il83mBoYgsSHmwZpUHxE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JPDs4ghLLTy+E2QN/9k2LLi5yvWHaJv7UJjGkDqej4ZadX+sbdyrH0+IeIiypsJif oDy1iIMjZvbt9+j/tDflFhierlij4w6CSCTznQxFX1cSLqzMh6rR+AtI90myKIvO/7 c/oPG7xoOYSmFAyjyKLMaZiVOqojO7heSTbkCS5I= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 51D02602FC Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=mojha@codeaurora.org Subject: Re: [PATCH] [V2] x86/asm: add __user on copy_user_handle_tail() pointers To: Ben Dooks , linux-kernel@vger.kernel.org Cc: x86@kernel.org, mingo@redhat.co, bp@alien8.de, hpa@zytor.com, torvalds@linux-foundation.org, tglx@linutronix.de References: <20190330115624.4000-1-ben.dooks@codethink.co.uk> From: Mukesh Ojha Message-ID: <65f52f59-3513-bf53-cb73-36bad40fad2d@codeaurora.org> Date: Sun, 31 Mar 2019 01:05:28 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190330115624.4000-1-ben.dooks@codethink.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/30/2019 5:26 PM, Ben Dooks wrote: > The copy_user_handle_tail() clearly uses both from and to as pointers > to user-space memory. This triggers sparse warning on using the calls > to get and put to user-space. This can be fixed easily by changing the > call to take __user annotated pointer.s > > arch/x86/lib/usercopy_64.c:68:21: warning: incorrect type in argument 1 (different address spaces) > arch/x86/lib/usercopy_64.c:68:21: expected void const volatile [noderef] * > arch/x86/lib/usercopy_64.c:68:21: got char * > arch/x86/lib/usercopy_64.c:70:21: warning: incorrect type in argument 1 (different address spaces) > arch/x86/lib/usercopy_64.c:70:21: expected void const volatile [noderef] * > arch/x86/lib/usercopy_64.c:70:21: got char *to > > From Linus Torvalds: > > On Thu, Mar 28, 2019 at 12:24 AM Borislav Petkov wrote: > > Well, but copy_user_generic() (which ends up calling the > copy_user_handle_tail() eventually) casts those __user pointers to > (__force void *). Converting them back to __user looks strange to me. > > Linus? > > Well, it does that because the x86 version of copy_user_generic() can > work in either direction, so it works when either the source or > destination (or both) are user pointers, but they don't _have_ to be. > > So the "userness" of a pointer in that context is a bit ambiguous, and > so we've picked the pointers to be just plain "void *". > > That said, arguably we should have gone the other way and just made > them both "__user" pointers, and do the cast the other way around. > > But there's no absolutely right answer here, and nobody should ever > use copy_user_generic() directly (ie it is very much meant to be only > used as a internal helper for the cases that get the pointer > annotations right). > > Signed-off-by: Ben Dooks Reviewed-by: Mukesh Ojha Cheers, -Mukesh > --- > arch/x86/include/asm/uaccess_64.h | 2 +- > arch/x86/lib/usercopy_64.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/include/asm/uaccess_64.h b/arch/x86/include/asm/uaccess_64.h > index a9d637bc301d..cbca2cb28939 100644 > --- a/arch/x86/include/asm/uaccess_64.h > +++ b/arch/x86/include/asm/uaccess_64.h > @@ -208,7 +208,7 @@ __copy_from_user_flushcache(void *dst, const void __user *src, unsigned size) > } > > unsigned long > -copy_user_handle_tail(char *to, char *from, unsigned len); > +copy_user_handle_tail(char __user *to, char __user *from, unsigned len); > > unsigned long > mcsafe_handle_tail(char *to, char *from, unsigned len); > diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c > index ee42bb0cbeb3..aa180424e77a 100644 > --- a/arch/x86/lib/usercopy_64.c > +++ b/arch/x86/lib/usercopy_64.c > @@ -60,7 +60,7 @@ EXPORT_SYMBOL(clear_user); > * it is not necessary to optimize tail handling. > */ > __visible unsigned long > -copy_user_handle_tail(char *to, char *from, unsigned len) > +copy_user_handle_tail(char __user *to, char __user *from, unsigned len) > { > for (; len; --len, to++) { > char c;