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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 05A5AC35240 for ; Fri, 24 Jan 2020 02:03:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9B23021835 for ; Fri, 24 Jan 2020 02:03:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9B23021835 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=zytor.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 099166B029D; Thu, 23 Jan 2020 21:03:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 021D46B029E; Thu, 23 Jan 2020 21:03:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E52B76B029F; Thu, 23 Jan 2020 21:03:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id CBFAB6B029D for ; Thu, 23 Jan 2020 21:03:51 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 826794DAD for ; Fri, 24 Jan 2020 02:03:51 +0000 (UTC) X-FDA: 76410881862.11.mask75_3eb2e46ce1a06 X-HE-Tag: mask75_3eb2e46ce1a06 X-Filterd-Recvd-Size: 5112 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Jan 2020 02:03:50 +0000 (UTC) Received: from [IPv6:2601:646:8600:3281:4dd4:188:b5a7:5dd5] ([IPv6:2601:646:8600:3281:4dd4:188:b5a7:5dd5]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id 00O23PpB1651500 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Jan 2020 18:03:28 -0800 Date: Thu, 23 Jan 2020 18:03:14 -0800 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not To: Linus Torvalds , christophe leroy CC: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Alexander Viro , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Jani Nikula , Linux Kernel Mailing List , linuxppc-dev , linux-fsdevel , Linux-MM , dri-devel , the arch/x86 maintainers From: hpa@zytor.com Message-ID: <1BC4F810-1BF4-4C15-9113-890A163FDBE2@zytor.com> 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: On January 23, 2020 11:57:57 AM PST, Linus Torvalds wrote: >On Thu, Jan 23, 2020 at 11:47 AM christophe leroy > wrote: >> >> 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=2E I'll >> respin tomorrow in that way=2E > >Ok, good=2E > >>From a "narrow the access window type" standpoint it does seem to be a >good idea to specify what kind of user accesses will be done, so I >don't hate the idea, it's more that I'm not convinced it matters >enough=2E > >On x86, we have made the rule that user_access_begin/end() can contain >_very_ few operations, and objtool really does enforce that=2E With >objtool and KASAN, you really end up with very small ranges of >user_access_begin/end()=2E > >And since we actually verify it statically on x86-64, I would say that >the added benefit of narrowing by access type is fairly small=2E We're >not going to have complicated code in that user access region, at >least in generic code=2E > >> > Also, it shouldn't be a "is this a write"=2E What if it's a read >_and_ a >> > write? Only a write? Only a read? >> >> Indeed that was more: does it includes a write=2E It's either RO or RW > >I would expect that most actual users would be RO or WO, so it's a bit >odd to have those choices=2E > >Of course, often writing ends up requiring read permissions anyway if >the architecture has problems with alignment handling or similar, but >still=2E=2E=2E The real RW case does exist conceptually (we have >"copy_in_user()", after all), but still feels like it shouldn't be >seen as the only _interface_ choice=2E > >IOW, an architecture may decide to turn WO into RW because of >architecture limitations (or, like x86 and arm, ignore the whole >RO/RW/WO _entirely_ because there's just a single "allow user space >accesses" flag), but on an interface layer if we add this flag, I >really think it should be an explicit "read or write or both"=2E > >So thus my "let's try to avoid doing it in the first place, but if we >_do_ do this, then do it right" plea=2E > > Linus I'm wondering if we should make it a static part of the API instead of a v= ariable=2E I have *deep* concern with carrying state in a "key" variable: it's a dire= ct attack vector for a crowbar attack, especially since it is by definition= live inside a user access region=2E One major reason x86 restricts the regions like this is to minimize the am= ount of unconstrained state: we don't save and restore the state around, bu= t enter and exit unconditionally, which means that a leaked state will end = up having a limited lifespan=2E Nor is there any state inside the user acce= ss region which could be corrupted to leave the region open=2E --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E