Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp77870ybb; Tue, 7 Apr 2020 17:18:19 -0700 (PDT) X-Google-Smtp-Source: APiQypIhCMZsT1qGWWuE6i5Ea5ZonCBofJcsGoxY228r7HNyUuxu1iZFyQF604jo7FzvicznndUh X-Received: by 2002:a4a:950b:: with SMTP id m11mr4081577ooi.83.1586305099549; Tue, 07 Apr 2020 17:18:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586305099; cv=none; d=google.com; s=arc-20160816; b=mrTOrnJe3p7ooXtO0KOJfBgyQTWmDYHgtgz6mAkjoRkjWnC2ui92atMl2dM8ILMXBJ Ws6eFtFBQ9FzSHWGoCKnoDNV2o+u/ak0RudM9ccL/lmJnVdYKTBxUVuzZ/2Bdjml4kK+ qUIXNQiE2p3XmjnQ76IIZ0BbZg1Ewl5om98Bev9bEj8aowNO1M3D/6mRXHnDeCith30a G0gI98Fnbowg22i2LRO8Las4NmiCWWKN/04GFX0xKgddbjE10rhH26o44U8QICvr3rx3 PQjo0vi2NBnKaIqgFRlQXeG8e68GrxhsutzzAOXOPiCXDzxzKLqwLBvVdCDMpAgNoWPd pKxA== 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; bh=PupYGUHq60lYZrZXsDDPw5nfMlPfp8W8S095Hkdx9y4=; b=zcWx2onH6wzIuApZFks5OEu89oR6+68jlPgaNuEnaeu8iaIr7Ja41N6WeklKKIwWDW UL1Xltkg4Z0t1SaifStpIit0LD7fs981ljbnMIzPVfP6RJRG59LQoGX2U0r1qCW0w+mE 34xomzN2JfY5GFJ3JgItnia40/5zZTkJ3xVf34+HygmnGSDcgcd49N+ONvbCT9awIPvP sEj2F6jMBIjO2Lwr36N3GSEAGM4p+CG0g3+MzKU4MKMOUpTUDz6gshP12oRxBlE3IqaB OX4GUtn3J1wGbTHvUeo054gSf9vTycWXcPo39Xq0mR2Egf+/FUc85BrfMfwLgGdvXvs1 /ZSw== ARC-Authentication-Results: i=1; mx.google.com; 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 i142si1199638oib.87.2020.04.07.17.18.04; Tue, 07 Apr 2020 17:18:19 -0700 (PDT) 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; 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 S1726523AbgDHAP6 (ORCPT + 99 others); Tue, 7 Apr 2020 20:15:58 -0400 Received: from www62.your-server.de ([213.133.104.62]:33280 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726420AbgDHAP5 (ORCPT ); Tue, 7 Apr 2020 20:15:57 -0400 Received: from sslproxy01.your-server.de ([78.46.139.224]) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1jLyNl-0003Wt-MF; Wed, 08 Apr 2020 02:15:53 +0200 Received: from [178.195.186.98] (helo=pc-9.home) by sslproxy01.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jLyNl-000CZ7-Bb; Wed, 08 Apr 2020 02:15:53 +0200 Subject: Re: Question on "uaccess: Add strict non-pagefault kernel-space read function" To: Christoph Hellwig Cc: Alexei Starovoitov , Linus Torvalds , Masami Hiramatsu , x86@kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, bgregg@netflix.com References: <20200403133533.GA3424@infradead.org> <5ddc8c04-279d-9a14-eaa7-755467902ead@iogearbox.net> <20200404093105.GA445@infradead.org> <2adc77e1-e84d-f303-fd88-133ec950c33f@iogearbox.net> <20200407093357.GA24309@infradead.org> From: Daniel Borkmann Message-ID: <776e5c99-57c9-b61b-d466-412db440a859@iogearbox.net> Date: Wed, 8 Apr 2020 02:15:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20200407093357.GA24309@infradead.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.102.2/25775/Tue Apr 7 14:53:51 2020) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/7/20 11:33 AM, Christoph Hellwig wrote: > On Tue, Apr 07, 2020 at 11:03:23AM +0200, Daniel Borkmann wrote: >> >> ... where archs with non-overlapping user and kernel address range would >> only end up having to implementing kernel_range_ok() check. Or, instead of >> a generic kernel_range_ok() this could perhaps be more probing-specific as >> in probe_kernel_range_ok() where this would then also cover the special >> cases we seem to have in parisc and um. Then, this would allow to get rid >> of all the __weak aliasing as well which may just be confusing. I could look >> into coming up with something along these lines. Thoughts? > > FYI, this is what I cooked up a few days ago: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/maccess-fixups > > Still misses the final work to switch probe_kernel_read to be the > strict version. Any good naming suggestion for the non-strict one? Ah great, thanks for working on it including the cleanups in your branch above. Good naming suggestion is usually the hardest ... ;-) Maybe adding an _unsafe or _lax suffix ... Regarding commits: * http://git.infradead.org/users/hch/misc.git/commitdiff/019f5d7894711a8046d1d57640d3db47f690c61e I think the extra HAVE_PROBE_KERNEL_ALLOWED / HAVE_PROBE_KERNEL_STRICT_ALLOWED reads a bit odd. Could we simply have an equivalent for access_ok() that archs implement under KERNEL_DS where it covers the allowed/restricted kernel-only range? Like mentioned earlier e.g. probe_{user,kernel}_range_ok() helpers where the user one defaults to access_ok() internally and the kernel one contains all the range restrictions that archs can then define if needed (and if not there could be an asm-generic `return true` fallback, for example). * http://git.infradead.org/users/hch/misc.git/commitdiff/2d6070ac749d0af26367892545d1c288cc00823a This would still need to set dst[0] = '\0' in that case to be consistent with the other error handling cases there when count > 0. Thanks, Daniel