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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable 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 28089C43381 for ; Sat, 23 Feb 2019 00:09:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ED0DE20651 for ; Sat, 23 Feb 2019 00:09:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="BXGnY8ug" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727482AbfBWAJU (ORCPT ); Fri, 22 Feb 2019 19:09:20 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:35460 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727405AbfBWAJT (ORCPT ); Fri, 22 Feb 2019 19:09:19 -0500 Received: by mail-lj1-f195.google.com with SMTP id j13-v6so3054051ljc.2 for ; Fri, 22 Feb 2019 16:09:18 -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=nfPdBRc9tHlVx4731kzoTxYm9oHOsR9CfjKri/wmKro=; b=BXGnY8uguxJoyc8/1beXM666q65BcuL7j71qhPOZoQUyrJTsEoBKigunyokVuT5Sla 4ZSIiA9wLPQk8l0PVwcbkAN6IHjqJgRLEWbiMC6B1kscR3ZELS9Pz/ujsOgRDUjwp2jT E29kxlYkUCPPjzT/j1SLuTWgPw6Jk+sZ74gY4= 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=nfPdBRc9tHlVx4731kzoTxYm9oHOsR9CfjKri/wmKro=; b=LQ6CyZ64l73glJe2G31HZej6QnZdYqUF76jXWG4/8PZabcJMQM2x8SNYqwsR2j2lZq VBIijLRYlz2I3zNGl+6Psaqa6mW//9clNVnaGDpI5zAprcjhchl59czCRXGYW6eplUGa TyAdI6wMiIzaH1U+EUXlMZtGHzhuWpUKX8fOZIWTTZY3QwY6Q5u8fj7lrQk7uyWDep/c Nb2q2xSIxVPVZhvjtk59Q4JeTxfpgBfQ+HUQUqMOYxZBF+LgM4/uaMJzA37aNk7sKZ3d ahWoDIVBu0OTD9HyztDoP5SJEsrNDvrmdFwjgeeDk7EjaBBJK6WgKLlZdgrbwUsUmobk zlVg== X-Gm-Message-State: AHQUAub0wpVpNVwJ00kXzarrBDY7oUSbvpVYXIbtFkN4o8OF3cqrsQa9 QMzCVgSxW00+b4Vxw1f42g1sv1BlDHw= X-Google-Smtp-Source: AHgI3IY+Bm7WZvUsgRP+Tn6Ixy+G7RLximPxzBRrBtb5ffwiQYf8Tjsk/D8R59E5HxN6c1/wz6m48w== X-Received: by 2002:a2e:9ad1:: with SMTP id p17mr3816662ljj.30.1550880557329; Fri, 22 Feb 2019 16:09:17 -0800 (PST) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com. [209.85.208.169]) by smtp.gmail.com with ESMTPSA id f141sm933539lfe.64.2019.02.22.16.09.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Feb 2019 16:09:16 -0800 (PST) Received: by mail-lj1-f169.google.com with SMTP id a17so3041897ljd.4 for ; Fri, 22 Feb 2019 16:09:15 -0800 (PST) X-Received: by 2002:a2e:8585:: with SMTP id b5mr3689553lji.125.1550880555567; Fri, 22 Feb 2019 16:09:15 -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> <20190222235618.dxewmv5dukltaoxl@ast-mbp.dhcp.thefacebook.com> In-Reply-To: <20190222235618.dxewmv5dukltaoxl@ast-mbp.dhcp.thefacebook.com> From: Linus Torvalds Date: Fri, 22 Feb 2019 16:08:59 -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: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Feb 22, 2019 at 3:56 PM Alexei Starovoitov wrote: > > It will preserve existing bpf_probe_read() behavior on x86. ... but that's the worst possible situation. It appears that people haven't understood that kernel and user addresses are distinct, and may have written programs that are fundamentally buggy. And we _want_ to make it clear that they are buggy on x86-64, exactly because x86-64 is the one that gets the most testing - by far. So if x86-64 continues working for buggy programs, then that only means that those bugs never get fixed. It would be much better to try to get those things fixed, and make the x86-64 implementation stricter, exactly so that people end up _realizing_ that they can't just think "a pointer is a pointer, and the context doesn't matter". >From a pure functional safety standpoint, I thought bpf already knew what kind of a pointer it had? Linus