Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1009882ybl; Thu, 23 Jan 2020 11:49:21 -0800 (PST) X-Google-Smtp-Source: APXvYqy+iEH8TKWSFQAZFbBckPDx+nptgvWOT79PN69Y19oBnMl/0Ix0b/CWkFrDT4J/7JFa9CMs X-Received: by 2002:aca:5fc6:: with SMTP id t189mr12138677oib.166.1579808961153; Thu, 23 Jan 2020 11:49:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579808961; cv=none; d=google.com; s=arc-20160816; b=nS+lOZ6BczGbOCVFHA+KDxWVqrP2v3KqP8HL6NHOxj0hl1kFShGEiO+MmqqI3/a5AC DOX8qVdcl29PlxDBzr5WYk8awaZqLpgwVxTxG7RerVeLUqKHXy7tKh2TMbUDRPVD78pk 4OhQs9SfA1n8s6rw3mgiQZpCwo7sV3UGPEpHDmk/Kl2636XU0QSDsqbEJ69NcMF/9Fat w71SsZLmT3Tr3rEf7f2xgWRhS5kuQlDUKTeDfruxDtQgSCe550SAuJ+Gu1LV7Thzf4Ig BYCWcL8NbE9yOMxEmHNOz3EFKhvadtpGzFayIT9xcKNzOZPYM0JDjxgKqHugyirNmzKd tTrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=7aISpSDwk7v2lI/VXtmtSlwWRv+BW39/h3hG4uOf4xk=; b=yD1YG0O5W5pfPk3GcUT05DYwA7sZhzlNm9Lc20NOrCoHTpMOCc/lsfLtYeIP1JIx1U H380XDEOsTg+VonLx5YqOiK/vzMlbm1D6KlerY6hdMSvghXUWfdgZELkSi7puvX8zvlU ieXKfVfPt8Uvcb9GwGQUQDGKbS3FquxY4FTtOGAK6b2D/ytegB+PS1l6S/+0Ozfu8H0V cBWsroaYMlzb5w0Ds53zIWER4+wUIGuOV5gjvpmqLnLQCNSUuB1eHQtg9Hde2sqr/CIW DsWysnTD73/akhe2T3z7sNLOn7YDgt7kDh8VUPeK2J+WMamJvwkm5dqLUpG5bH6SR5A6 x6fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b=GiT4oOAM; 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 y23si1611131oti.65.2020.01.23.11.49.08; Thu, 23 Jan 2020 11:49:21 -0800 (PST) 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=@c-s.fr header.s=mail header.b=GiT4oOAM; 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 S1728921AbgAWTrO (ORCPT + 99 others); Thu, 23 Jan 2020 14:47:14 -0500 Received: from pegase1.c-s.fr ([93.17.236.30]:61664 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726167AbgAWTrN (ORCPT ); Thu, 23 Jan 2020 14:47:13 -0500 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 Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 200122-2, 22/01/2020), Outbound message X-Antivirus-Status: Not-Tested Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 23/01/2020 à 19:02, Linus Torvalds a écrit : > 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. > > 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 ppc64. On it, you can unlock either read or write or both. And this is what is done for get_user() / put_user() and friends: unlock only reads for get_user() and only writes for put_user(). Could also be a compromise between performance and security: keeping reads allowed at all time and only protect against writes on modern architectures which support it like ppc64. > > 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 second step later after evaluating the real performance impact. I'll respin tomorrow in that way. > > But if we really do want to do this, then: Indeed I took the idea from a discussion in last Octobre (Subject: "book3s/32 KUAP (was Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user())" ) https://lore.kernel.org/lkml/87h84avffi.fsf@mpe.ellerman.id.au/ > >> 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(). > > You should make it more opaque than "unsigned long". > > 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