Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp1985924imc; Fri, 22 Feb 2019 15:17:06 -0800 (PST) X-Google-Smtp-Source: AHgI3IaXOzWjTKyef0Y6R3CP2xhGkKJDAlDT6mVNJHedgZMVX5Cut6pJZcA1H+D7kdTpPWHJFRq4 X-Received: by 2002:a63:4d4f:: with SMTP id n15mr6295225pgl.327.1550877426161; Fri, 22 Feb 2019 15:17:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550877426; cv=none; d=google.com; s=arc-20160816; b=iHm47PuBBw+rlmIDenWaa9t3OT8f9c8VZmh+MMEBBtE6l8VkRciN05fiNWHU34QBgz s9zx0ym9n7YyN4rJAVB9X9HtPeoryThoa321X7AqygpQvKmMhs2aFc44xsjti2WJ8dC5 8dmTd62Yxl2kmM9J6z7NujhfENI6QKhVYqLe1gNRntVX9pDNXqp9Gd60URTBROvEfNeH dritA/90qpMCby2r5m6SUqk+Ekpy4V9KALYCuA8nAjuh1pFSvyX654mjkkrsqApVFGDD 2X5YStQyBTU2mgqZqqB44OlpsG2af+odZKVmOhoN0jXa25I9kREiicduEIL8G8MWB5zi /O0g== 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:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=E3akVKOIlu3I+B2JKMsBtv50M2PmNBlS3OjvgeyXaHU=; b=mIRjVEFRg8APIg0C7niOCeooNB0wLvhtD9JbUg0qJBM5Pp38VrblDptH9UVuN8g2Q/ 3gC7b9L5e6uyL27yaTPsVarsZHXL+6kh6Ihp43XclB3YOZZ2/7+Juj09qy0SfZR23i20 IGF+Exn600DxSbnO2DKS6kafGX8KQkaPGghmuHTpn1EqOt+lC8MqQezQB4LEJSMsmiGA AY1rCc1+EzJMQA3+gA8ih7xqDjiQMMSV9pnfnY3P1CbQ4jebW0/coSbU8XDq8K/9YU/I yz8JAM/viDC+GHPPGMs3+iR2bejpJG9yo5OQDpb1qH3SlrnP/lAZMhc8H08AB+Kn0PM6 y4ig== 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 c17si2493749pfb.81.2019.02.22.15.16.50; Fri, 22 Feb 2019 15:17:06 -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; 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 S1727176AbfBVXQK (ORCPT + 99 others); Fri, 22 Feb 2019 18:16:10 -0500 Received: from shards.monkeyblade.net ([23.128.96.9]:59654 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725774AbfBVXQK (ORCPT ); Fri, 22 Feb 2019 18:16:10 -0500 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::bf5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 47A7414AD91EC; Fri, 22 Feb 2019 15:16:09 -0800 (PST) Date: Fri, 22 Feb 2019 15:16:06 -0800 (PST) Message-Id: <20190222.151606.344940961752699587.davem@davemloft.net> To: jannh@google.com Cc: alexei.starovoitov@gmail.com, torvalds@linux-foundation.org, mhiramat@kernel.org, rostedt@goodmis.org, luto@amacapital.net, linux-kernel@vger.kernel.org, mingo@kernel.org, akpm@linux-foundation.org, stable@vger.kernel.org, changbin.du@gmail.com, keescook@chromium.org, luto@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault From: David Miller In-Reply-To: References: <20190222225103.o5rr5zr4fq77jdg4@ast-mbp.dhcp.thefacebook.com> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 22 Feb 2019 15:16:09 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jann Horn Date: Sat, 23 Feb 2019 00:11:58 +0100 > I think what Linus is saying is: There are some scenarios (like a > system with the old 4G/4G X86 patch) where *the same* address can > refer to two different pieces of memory, depending on whether you > interpret it as a kernel pointer or a user pointer. Exactly. On sparc64 the kernel is mapped exactly at the same virtual addresses as userspace processes usually are mapped, even 32-bit ones. The difference is the MMU context only.