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.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 B2E47C433E1 for ; Tue, 2 Jun 2020 17:18:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 90954206C3 for ; Tue, 2 Jun 2020 17:18:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591118312; bh=tb+xyliGtwI1tI3gv1PbxDFbgWXAWbvy+WEHLVNEd4k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=uoyhxAXrL8822+5EQ3cefMt9AlCQnAdKQ/PKOAfyWq6V6dLORNe78mA/VrhE71d6m q3dWgGB0LNWPjt6fAK3PeXp0NInwLohaYEyCBTThKq/FS2HEroSsw3udr+MANmgpPy thv0ugMdCG2LB/sA55bfoorCz3AuMFVqx7vCYZs0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726666AbgFBRSb (ORCPT ); Tue, 2 Jun 2020 13:18:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725969AbgFBRSa (ORCPT ); Tue, 2 Jun 2020 13:18:30 -0400 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42879C05BD1E for ; Tue, 2 Jun 2020 10:18:29 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id z18so13495924lji.12 for ; Tue, 02 Jun 2020 10:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SNRBsgEhndaWfJkwxqUhFkYrHA7Z2jK8v+SKAjBpMrw=; b=cHeKntEgM3HiICfht/pnCtDkCgAraRt+vGaiFUa0rbQQRGNJUmWfN31GQWT3/8Ltqs xGyw9NW6GGE0qRN1zYrj5A1Lp+0See6177U9da0iJoS/+M/e7Y5lNanIyNFQmxAWsbyv Eqfz4HZv3uqTzo08M9Ioc36wztuAz4V5eRnsY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SNRBsgEhndaWfJkwxqUhFkYrHA7Z2jK8v+SKAjBpMrw=; b=Wl4D3mWvyOc3VP4HBW3GhaGOECFrQQz/CDXRWq6w/TRdVLscCokpd1o7CRe4SbGWNu GedcgHpyOG+u3s6DV5JpV1HDROyYAxWH9rrWaSweD2FGYgAgk6Y4e5IjBHjZDvL1mJEh +VRH17N2k0Rqi47f/Z9JG23XCP+8aBksmxgLw0E/yIqCQ2WXtGl05ArfszXhqNh+wiaP ZUkSnqWt9XCUgT3WIh/nVN907SZJNiDOFNVvCbfkNzOlYRhUXGRHcgrNZuZ7r1KaqnzY tONCsye9wqtkYK8geOSwL0WJIwfk8RqIRQ342pkobtCByzqEuZJ+cIJme3hJm+5SQ2ma TGxw== X-Gm-Message-State: AOAM531Sj5bjB8gGmTvCsMaslrgDgjmziHMqaceaZ8roFT/Ctbn8QsmX 0uy4OKQZ2+XfVfL4YNbSgOvv7Jl+i3k= X-Google-Smtp-Source: ABdhPJyV9EMKJs7+VtVQZzX1DCH2zxLJYF9SFGtcM0tZwDj+VR6zh8BU34OtNVoDm6QJ+Um4RnXYOA== X-Received: by 2002:a05:651c:82:: with SMTP id 2mr63881ljq.341.1591118307200; Tue, 02 Jun 2020 10:18:27 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id 205sm833109lfe.73.2020.06.02.10.18.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 10:18:26 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id e125so6668211lfd.1 for ; Tue, 02 Jun 2020 10:18:25 -0700 (PDT) X-Received: by 2002:ac2:504e:: with SMTP id a14mr235578lfm.30.1591118305358; Tue, 02 Jun 2020 10:18:25 -0700 (PDT) MIME-Version: 1.0 References: <20200602084257.134555-1-mst@redhat.com> <20200602163306.GM23230@ZenIV.linux.org.uk> In-Reply-To: <20200602163306.GM23230@ZenIV.linux.org.uk> From: Linus Torvalds Date: Tue, 2 Jun 2020 10:18:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok() To: Al Viro Cc: Jason Wang , "Michael S. Tsirkin" , Linux Kernel Mailing List , Netdev Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Jun 2, 2020 at 9:33 AM Al Viro wrote: > > > > > It's not clear whether we need a new API, I think __uaccess_being() has the > > assumption that the address has been validated by access_ok(). > > __uaccess_begin() is a stopgap, not a public API. Correct. It's just an x86 implementation detail. > The problem is real, but "let's add a public API that would do user_access_begin() > with access_ok() already done" is no-go. Yeah, it's completely pointless. The solution to this is easy: remove the incorrect and useless early "access_ok()". Boom, done. Then use user_access_begin() and the appropriate unsage_get/put_user() sequence, and user_access_end(). The range test that user-access-begin does is not just part of the ABI, it's just required in general. We have almost thirty years of history of trying to avoid it, AND IT WAS ALL BOGUS. The fact is, the range check is pretty damn cheap, and not doing the range check has always been a complete and utter disaster. You have exactly two cases: (a) the access_ok() would be right above the code and can't be missed (b) not and in (a) the solution is: remove the access_ok() and let user_access_begin() do the range check. In (b), the solution is literally "DON'T DO THAT!" Because EVERY SINGLE TIME people have eventually noticed (possibly after code movement) that "oops, we never did the access_ok at all, and now we can be fooled into kernel corruption and a security issue". And even if that didn't happen, the worry was there. End result: use user_access_begin() and stop trying to remove the two cycles or whatever of the limit checking cost. The "upside" of removing that limit check just isn't. It's a downside. Linus