Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp766411ybk; Wed, 13 May 2020 12:30:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzx8ui2Mug4ItZ4gbXLMU3CqcBNorpxvWhAvZ78M7D9WKntlpgVrQCFQtgg60+QbbDXxZmt X-Received: by 2002:a50:d6d0:: with SMTP id l16mr1136937edj.317.1589398245594; Wed, 13 May 2020 12:30:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589398245; cv=none; d=google.com; s=arc-20160816; b=kD1YxNs8g0Zp/aWl4/WBChAxHAavnpRpnSJq7RHhpMNtljWKx+iCDdMPAqFsZ6p6Ta eV8A1I4TPrq6VCI6kZXizVbTQ4KD/bUjG13rcu+vluGaETh9IMZ3effhwHL8pzJd3oFh PFMcOsD+boyiZQisMLnFvF/KMBADHap5Kg65XaW4ZpK34GsYQr9ODZOQNGp+fJRtoINg 5VaekNG6IOz54Ho93RthJmiXdfhzlOK9mY/ByDBC2xgEEz81y2idocklK2/WkFkBwGgu rUe7fV2qR8C0YzSawzZk7OoTOtDu6Ts6yNUejIZUtquoXAjGKLlqrpFavn1voNk8OWRM YSGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=uGM0fHSyMNnN8KkwE4ZHbjKv3Yq6bhbhqlHQnOB61Eg=; b=OrHjDGr9kKUeM3mHwoS2JIm0ksKE8aOXWKkv/UUDQtBWEOT1W9TCUqmXTQzkrCcH0w F50+AW8+K6BJg8MRuIIdyihbieeW7X8q7blnEbX0UC2UbOq1D3Fk6EPAE1n3w+qEuYHm tQPqOuAe12EEWgbyuujQ84GJjTOmOdZ65ZqCJFWb/Y14Ehj326xfwTERHjWGaU6Ca2Zj gE9PeWC56jql3lHnOBWxkggzZlXqBKAG+RlZw/qCwIpkt4AjAG2YE8ULzdQ1vw4y9Ryp GVfZn7a1SO1hFodWs+oW76CfZFjOjpWLbqKWJCRHalek2MdKSBgORrC/2psRMnwhXd4y +rAQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c2si401498ejd.263.2020.05.13.12.30.21; Wed, 13 May 2020 12:30:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390687AbgEMT2J (ORCPT + 99 others); Wed, 13 May 2020 15:28:09 -0400 Received: from verein.lst.de ([213.95.11.211]:48313 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390291AbgEMT2J (ORCPT ); Wed, 13 May 2020 15:28:09 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 3747968B05; Wed, 13 May 2020 21:28:05 +0200 (CEST) Date: Wed, 13 May 2020 21:28:04 +0200 From: Christoph Hellwig To: Linus Torvalds Cc: Christoph Hellwig , the arch/x86 maintainers , Alexei Starovoitov , Daniel Borkmann , Masami Hiramatsu , Andrew Morton , linux-parisc@vger.kernel.org, linux-um , Netdev , bpf@vger.kernel.org, Linux-MM , Linux Kernel Mailing List Subject: Re: [PATCH 11/18] maccess: remove strncpy_from_unsafe Message-ID: <20200513192804.GA30751@lst.de> References: <20200513160038.2482415-1-hch@lst.de> <20200513160038.2482415-12-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 13, 2020 at 12:11:27PM -0700, Linus Torvalds wrote: > On Wed, May 13, 2020 at 9:01 AM Christoph Hellwig wrote: > > > > +static void bpf_strncpy(char *buf, long unsafe_addr) > > +{ > > + buf[0] = 0; > > + if (strncpy_from_kernel_nofault(buf, (void *)unsafe_addr, > > + BPF_STRNCPY_LEN)) > > + strncpy_from_user_nofault(buf, (void __user *)unsafe_addr, > > + BPF_STRNCPY_LEN); > > +} > > This seems buggy when I look at it. > > It seems to think that strncpy_from_kernel_nofault() returns an error code. > > Not so, unless I missed where you changed the rules. I didn't change the rules, so yes, this is wrong. > Also, I do wonder if we shouldn't gate this on TASK_SIZE, and do the > user trial first. On architectures where this thing is valid in the > first place (ie kernel and user addresses are separate), the test for > address size would allow us to avoid a pointless fault due to an > invalid kernel access to user space. > > So I think this function should look something like > > static void bpf_strncpy(char *buf, long unsafe_addr) > { > /* Try user address */ > if (unsafe_addr < TASK_SIZE) { > void __user *ptr = (void __user *)unsafe_addr; > if (strncpy_from_user_nofault(buf, ptr, BPF_STRNCPY_LEN) >= 0) > return; > } > > /* .. fall back on trying kernel access */ > buf[0] = 0; > strncpy_from_kernel_nofault(buf, (void *)unsafe_addr, > BPF_STRNCPY_LEN); > } > > or similar. No? So on say s390 TASK_SIZE_USUALLy is (-PAGE_SIZE), which means we'd alway try the user copy first, which seems odd. I'd really like to here from the bpf folks what the expected use case is here, and if the typical argument is kernel or user memory.