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.0 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 8A051C2D0DB for ; Thu, 23 Jan 2020 19:47:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 50B4C21D7D for ; Thu, 23 Jan 2020 19:47:14 +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="GiT4oOAM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50B4C21D7D 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 CD7596B0273; Thu, 23 Jan 2020 14:47:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C60B26B0274; Thu, 23 Jan 2020 14:47:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B26FF6B0275; Thu, 23 Jan 2020 14:47:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0039.hostedemail.com [216.40.44.39]) by kanga.kvack.org (Postfix) with ESMTP id 959886B0273 for ; Thu, 23 Jan 2020 14:47:13 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 519942473 for ; Thu, 23 Jan 2020 19:47:13 +0000 (UTC) X-FDA: 76409932746.02.net26_79336f31e5b61 X-HE-Tag: net26_79336f31e5b61 X-Filterd-Recvd-Size: 5573 Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Thu, 23 Jan 2020 19:47:12 +0000 (UTC) Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 483Xq32wGFz9twsF; Thu, 23 Jan 2020 20:47:11 +0100 (CET) Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=GiT4oOAM; 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 SdrD6o_7qs43; Thu, 23 Jan 2020 20:47:11 +0100 (CET) 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 483Xq31j0Sz9twsD; Thu, 23 Jan 2020 20:47:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1579808831; bh=7aISpSDwk7v2lI/VXtmtSlwWRv+BW39/h3hG4uOf4xk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GiT4oOAMsDoIJbqHVSxG301CAWwldgZmQRaIfFMSVrBDbBc/V9IXlyBKUf1FQX89s crLgitQifrTzbgyEVrCPJRbrcv2z6CpXbA2e1nkKThpAmm/AlGNMSMpu/ixIreuf5B KfqT02ezurVVK0RQGGtRw0A4me1TlQkiUzi+NGDM= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 3C6F28B837; Thu, 23 Jan 2020 20:47:11 +0100 (CET) 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 LHxckWJhJw66; Thu, 23 Jan 2020 20:47:11 +0100 (CET) Received: from [192.168.232.53] (unknown [192.168.232.53]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 151148B836; Thu, 23 Jan 2020 20:47:10 +0100 (CET) Subject: Re: [PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not To: Linus Torvalds Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Alexander Viro , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Jani Nikula , Linux Kernel Mailing List , linuxppc-dev , linux-fsdevel , Linux-MM , dri-devel , the arch/x86 maintainers References: From: christophe leroy Message-ID: Date: Thu, 23 Jan 2020 20:47:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr X-Antivirus: Avast (VPS 200122-2, 22/01/2020), Outbound message X-Antivirus-Status: Not-Tested 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 23/01/2020 =C3=A0 19:02, Linus Torvalds a =C3=A9crit=C2=A0: > On Thu, Jan 23, 2020 at 4:59 AM Christophe Leroy > wrote: >> >> On 32 bits powerPC (book3s/32), only write accesses to user are >> protected and there is no point spending time on unlocking for reads. >=20 > Honestly, I'm starting to think that 32-bit ppc just needs to look > more like everybody else, than make these changes. Well, beside ppc32, I was also seen it as an opportunity for the modern=20 ppc64. On it, you can unlock either read or write or both. And this is=20 what is done for get_user() / put_user() and friends: unlock only reads=20 for get_user() and only writes for put_user(). Could also be a compromise between performance and security: keeping=20 reads allowed at all time and only protect against writes on modern=20 architectures which support it like ppc64. >=20 > We used to have a read/write argument to the old "verify_area()" and > "access_ok()" model, and it was a mistake. It was due to odd i386 user > access issues. We got rid of it. I'm not convinced this is any better > - it looks very similar and for odd ppc access issues. I'm going to leave it aside, at least for the time being, and do it as a=20 second step later after evaluating the real performance impact. I'll=20 respin tomorrow in that way. >=20 > But if we really do want to do this, then: Indeed I took the idea from a discussion in last Octobre (Subject:=20 "book3s/32 KUAP (was Re: [PATCH] Convert filldir[64]() from __put_user()=20 to unsafe_put_user())" ) https://lore.kernel.org/lkml/87h84avffi.fsf@mpe.ellerman.id.au/ >=20 >> Add an argument to user_access_begin() to tell when it's for write and >> return an opaque key that will be used by user_access_end() to know >> what was done by user_access_begin(). >=20 > You should make it more opaque than "unsigned long". >=20 > Also, it shouldn't be a "is this a write". What if it's a read _and_ a > write? Only a write? Only a read? Indeed that was more: does it includes a write. It's either RO or RW Christophe