Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp1987411imc; Fri, 22 Feb 2019 15:19:08 -0800 (PST) X-Google-Smtp-Source: AHgI3IbPdwHM6TLax5paatOgBqhJL4ZUT/PKbw2BdD3PhBKgBr7QMvnsWZ5supeUC7EECF4ANoLj X-Received: by 2002:a62:ea09:: with SMTP id t9mr6950577pfh.228.1550877548448; Fri, 22 Feb 2019 15:19:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550877548; cv=none; d=google.com; s=arc-20160816; b=Nk2f6GiwXYu/rkJ/kZHBiyI4/B/+22ZA4MjYKy9aHIQnRXBzxQACDJLC+Odw3XVJJn K6llAph6HnD7MylbYfdhZVzISag6n3jBABNbIFt3RUmgQ7foek0uqxk5n7hBAsUnnQDa FiY8qEhaOQkj9bP/ZEH4esv90klpSzRmC8ubFdp+wpEANw1hJkNPVyzL9pH72aTc6zTK 5/bFgU2k7eudWniLsCCZhFJLV3rJmpw4eqN7/9uld5q29eZVDia7pIQZLaMHU5aqNAGy 5LtjYDTAfby1QTYv2QRsb562BV/ssmP7febGCdYBlDsmStJRrYj18lWM2E1TvuNpjEat ZuNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=JbkNOJOWOEztY0V5oFI3crYnBu0yHTs4i1TRjvJWTnk=; b=TU+O7WMEdd2fbkvf0hreCjx7xuRMHUkpwcH5YF7TIjTEP08A9mOcnk8T2kTkjmA6PL I0GiEHESoSrbuVJhUdBebzjlbtZeOzSsU/tR7JxDpNBrQwnxzDDwwmT+rRE9H1RmpG2S AGYqvySDi7SsGv02aNX6ZMzkXItN6zItbUXFFZo+SNkwd04AJlrtl5Q8XAvTr7hcf7SW 06uqJmHM+OVhCfA6GTcFMyEB8uVPXUPCe9yYUQmTCRbtQGAMs/bgnLTQrlDuHbgeyLAZ pMGvCo2FAFdF5bdlDl4TDKe1knW3XOYKlnn83zC154uEuk9svn4V7bzhaWtESKsWhtb/ G1Gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=Z8RmPI2o; 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 88si2480118plb.288.2019.02.22.15.18.52; Fri, 22 Feb 2019 15:19:08 -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; dkim=pass header.i=@linux-foundation.org header.s=google header.b=Z8RmPI2o; 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 S1727332AbfBVXQz (ORCPT + 99 others); Fri, 22 Feb 2019 18:16:55 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:46696 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725774AbfBVXQz (ORCPT ); Fri, 22 Feb 2019 18:16:55 -0500 Received: by mail-lj1-f196.google.com with SMTP id v16so2939158ljg.13 for ; Fri, 22 Feb 2019 15:16:53 -0800 (PST) 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=JbkNOJOWOEztY0V5oFI3crYnBu0yHTs4i1TRjvJWTnk=; b=Z8RmPI2oG03C9S+ZOdCOIl/Pr8NpV9R6t/ZeMxGfSr4B+ZkHiyBc2yvrG9i4Otkatk erfitGEiOAqqehH6AbUlzDJxNUFjj/rL5EmXsL3FAiMizVQq1qBzGeWQ7X3jmSg6XkON zing7Tgfl1Kl9mUlx4H2aKtNYu/VU4kgyM83s= 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=JbkNOJOWOEztY0V5oFI3crYnBu0yHTs4i1TRjvJWTnk=; b=patmBozgNeDoB+f4Z/NXx4kGq8fgIJp93KN867hiKQU/dLgtb1cSJ316+o3fswrb4U 5lgaGGMam2X1v1CuiA0hlLUOqfQ8D7qNLMs5y4vFRYXozEqczqlClOSkllxOXasoX/Nx MbzWQSVV2bXjtxkoh+rYmNJ04pcTw2LUVRtwpY30kpSwEbfP6EXwtMuA+V3rm9tPQum2 eFhpNK0YiQqeLErUCymeUqK9fBNhmneYGIx4OZ15YRQNLbjgLg3SzrxjvCCskjPHd9Za lgSJl0CvwFdwYnAphCe+19AqOHw+386ZZi6+dPqNkUNxqdJf9+Fmb3Atx+EZiIUYqlsh QbSw== X-Gm-Message-State: AHQUAubAjHx52UGkp396idbALT79lYLcnq4sjhnEBPEuVIY66BmRt4co yD743kBcpWWvqcTZNd1I4gvW0GY9lDs= X-Received: by 2002:a2e:80d6:: with SMTP id r22mr3291101ljg.148.1550877413035; Fri, 22 Feb 2019 15:16:53 -0800 (PST) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id v65sm814313lje.77.2019.02.22.15.16.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Feb 2019 15:16:52 -0800 (PST) Received: by mail-lf1-f51.google.com with SMTP id q11so2966550lfd.3 for ; Fri, 22 Feb 2019 15:16:52 -0800 (PST) X-Received: by 2002:ac2:415a:: with SMTP id c26mr4153706lfi.62.1550877412019; Fri, 22 Feb 2019 15:16:52 -0800 (PST) MIME-Version: 1.0 References: <20190222192703.epvgxghwybte7gxs@ast-mbp.dhcp.thefacebook.com> <20190222.133842.1637029078039923178.davem@davemloft.net> <20190222225103.o5rr5zr4fq77jdg4@ast-mbp.dhcp.thefacebook.com> In-Reply-To: <20190222225103.o5rr5zr4fq77jdg4@ast-mbp.dhcp.thefacebook.com> From: Linus Torvalds Date: Fri, 22 Feb 2019 15:16:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault To: Alexei Starovoitov Cc: David Miller , Masami Hiramatsu , Steven Rostedt , Andy Lutomirski , Linux List Kernel Mailing , Ingo Molnar , Andrew Morton , stable , Changbin Du , Jann Horn , Kees Cook , Andrew Lutomirski , Daniel Borkmann , Netdev , bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 22, 2019 at 2:51 PM Alexei Starovoitov wrote: > > That's all fine. I'm missing rationale for making probe_kernel_read() > fail on user addresses. Because it already WON'T WORK in general! > What is fundamentally wrong with a function probe_any_address_read() ? What part of "the same pointer value can be a user address and a kernel address" is not getting through? The user address space and the kernel address space have separate page tables on some architectures. We used to avoid it on x86, because switching address spaces was expensive, but even on x86 some vendors did it on 32-bit simply to get 4GB of user (and kernel) address space. And now we end up doing it anyway just because of meltdown. So a kernel pointer value of 0x12345678 could be a value kernel pointer pointing to some random kmalloc'ed kernel memory, and a user pointer value of 0x12345678 could be a valid _user_ pointer pointing to some user mapping. See? If you access a user pointer, you need to use a user accessor function (eg "get_user()"), while if you access a kernel pointer you need to just dereference it directly (unless you can't trust it, in which case you need to use a _different_ accessor function). The fact that user and kernel pointers happen to be distinct on x86-64 (right now) is just a random implementation detail. Really. I didn't realize how many people seem to have been confused about this. But it's always been true. It's just that the common architectures have had that "one single address space for both kernel and user pointers" in practice. In fact, the *very* first kernel version had separate address spaces for kernel and user mode even on x86 (using segments, not paging). So it has literally been true since day one in Linux that a kernel address can be indistinguishable from a user address from a pure value standpoint. Linus