From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3DB39C2BA12 for ; Thu, 2 Apr 2020 17:03:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A37782078B for ; Thu, 2 Apr 2020 17:03:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=c-s.fr header.i=@c-s.fr header.b="ACiTytRZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A37782078B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=c-s.fr Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 358418E0008; Thu, 2 Apr 2020 13:03:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32F2D8E0007; Thu, 2 Apr 2020 13:03:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F70D8E0008; Thu, 2 Apr 2020 13:03:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) by kanga.kvack.org (Postfix) with ESMTP id 06D118E0007 for ; Thu, 2 Apr 2020 13:03:34 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id BEF6A611D for ; Thu, 2 Apr 2020 17:03:33 +0000 (UTC) X-FDA: 76663536306.17.color65_1d6a53d7941e X-HE-Tag: color65_1d6a53d7941e X-Filterd-Recvd-Size: 7277 Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Thu, 2 Apr 2020 17:03:32 +0000 (UTC) Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 48tTsr5rRRz9vBmV; Thu, 2 Apr 2020 19:03:28 +0200 (CEST) Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=ACiTytRZ; dkim-adsp=pass; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id AvlDP2sR7zTb; Thu, 2 Apr 2020 19:03:28 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 48tTsr4JmWz9vBmS; Thu, 2 Apr 2020 19:03:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1585847008; bh=JzGfy64woJ08evugoWBAVtqz/vtq+HHi55dh1/1+x5A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ACiTytRZC+Xj1EuNnjHaWbbYCnJ8CD46NNiCXRQXdSw8VyzeFkJ2iXIguFAur/WXP cGiaTz0jzh4b++Xtfz3FYdDzGi39XWjPpP47djmAbDbgW6+Qcumeu76BQzwby7Kadg qsGptG6uO/KhtseD57NVkod6GcuUBabHLVYA7YLY= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id EDF298B93A; Thu, 2 Apr 2020 19:03:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id IdlgMSKFOZLT; Thu, 2 Apr 2020 19:03:29 +0200 (CEST) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id C52AF8B925; Thu, 2 Apr 2020 19:03:28 +0200 (CEST) Subject: Re: [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end To: Al Viro Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , airlied@linux.ie, daniel@ffwll.ch, torvalds@linux-foundation.org, akpm@linux-foundation.org, keescook@chromium.org, hpa@zytor.com, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, Russell King , Christian Borntraeger References: <27106d62fdbd4ffb47796236050e418131cb837f.1585811416.git.christophe.leroy@c-s.fr> <20200402162942.GG23230@ZenIV.linux.org.uk> From: Christophe Leroy Message-ID: <67e21b65-0e2d-7ca5-7518-cec1b7abc46c@c-s.fr> Date: Thu, 2 Apr 2020 19:03:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200402162942.GG23230@ZenIV.linux.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Le 02/04/2020 =C3=A0 18:29, Al Viro a =C3=A9crit=C2=A0: > On Thu, Apr 02, 2020 at 07:34:16AM +0000, Christophe Leroy wrote: >> Some architectures like powerpc64 have the capability to separate >> read access and write access protection. >> For get_user() and copy_from_user(), powerpc64 only open read access. >> For put_user() and copy_to_user(), powerpc64 only open write access. >> But when using unsafe_get_user() or unsafe_put_user(), >> user_access_begin open both read and write. >> >> Other architectures like powerpc book3s 32 bits only allow write >> access protection. And on this architecture protection is an heavy >> operation as it requires locking/unlocking per segment of 256Mbytes. >> On those architecture it is therefore desirable to do the unlocking >> only for write access. (Note that book3s/32 ranges from very old >> powermac from the 90's with powerpc 601 processor, till modern >> ADSL boxes with PowerQuicc II modern processors for instance so it >> is still worth considering) >> >> In order to avoid any risk based of hacking some variable parameters >> passed to user_access_begin/end that would allow hacking and >> leaving user access open or opening too much, it is preferable to >> use dedicated static functions that can't be overridden. >> >> Add a user_read_access_begin and user_read_access_end to only open >> read access. >> >> Add a user_write_access_begin and user_write_access_end to only open >> write access. >> >> By default, when undefined, those new access helpers default on the >> existing user_access_begin and user_access_end. >=20 > The only problem I have is that we'd better choose the calling > conventions that work for other architectures as well. >=20 > AFAICS, aside of ppc and x86 we have (at least) this: > arm: > unsigned int __ua_flags =3D uaccess_save_and_enable(); > ... > uaccess_restore(__ua_flags); > arm64: > uaccess_enable_not_uao(); > ... > uaccess_disable_not_uao(); > riscv: > __enable_user_access(); > ... > __disable_user_access(); > s390/mvc: > old_fs =3D enable_sacf_uaccess(); > ... > disable_sacf_uaccess(old_fs); >=20 > arm64 and riscv are easy - they map well on what we have now. > The interesting ones are ppc, arm and s390. >=20 > You wants to specify the kind of access; OK, but... it's not just read > vs. write - there's read-write as well. AFAICS, there are 3 users of > that: > * copy_in_user() > * arch_futex_atomic_op_inuser() > * futex_atomic_cmpxchg_inatomic() > The former is of dubious utility (all users outside of arch are in > the badly done compat code), but the other two are not going to go > away. user_access_begin() grants both read and write. This patch adds user_read_access_begin() and user_write_access_begin()=20 but it doesn't remove user_access_begin() >=20 > What should we do about that? Do we prohibit such blocks outside > of arch? >=20 > What should we do about arm and s390? There we want a cookie passed > from beginning of block to its end; should that be a return value? That was the way I implemented it in January, see=20 https://patchwork.ozlabs.org/patch/1227926/ There was some discussion around that and most noticeable was: H. Peter (hpa) said about it: "I have *deep* concern with carrying state=20 in a "key" variable: it's a direct attack vector for a crowbar attack,=20 especially since it is by definition live inside a user access region." >=20 > And at least on arm that thing nests (see e.g. __clear_user_memset() > there), so "stash that cookie in current->something" is not a solution.= .. >=20 > Folks, let's sort that out while we still have few users of that > interface; changing the calling conventions later will be much harder. > Comments? >=20 This patch minimises the change by just adding user_read_access_begin()=20 and user_write_access_begin() keeping the same parameters as the=20 existing user_access_begin(). So I can come back to a mix of this patch and the January version if it=20 corresponds to everyone's view, it will also be a bit easier for powerpc=20 (especially book3s/32). But that didn't seem to be the expected=20 direction back when we discussed it in January. Christophe