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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 C076EC43613 for ; Mon, 24 Jun 2019 20:09:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9195520657 for ; Mon, 24 Jun 2019 20:09:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561406941; bh=yZharV4FdSmnh4ESX5hlMEMyGkbzv5g/opBE0Yc/f0I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=stA3sLMnDYYonA4iXzDbj2+gSsZKT1Rtjb0jrBbsjdoA9/U1TNjZZEJK3Etp8va6u GwQ8hPPBvWvObEO/haE1GF1cigAKhp0dtdLIsIH26Cg1uVnprkDcELOFa8IgbJ1HPn tGnq9U7nQDo97sJeXvV+/b0OHhXQpJjw5NfebAas= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731546AbfFXUJA (ORCPT ); Mon, 24 Jun 2019 16:09:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:44256 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731486AbfFXUI6 (ORCPT ); Mon, 24 Jun 2019 16:08:58 -0400 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8047B208E3 for ; Mon, 24 Jun 2019 20:08:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561406937; bh=yZharV4FdSmnh4ESX5hlMEMyGkbzv5g/opBE0Yc/f0I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Y1IekffKS026ESmMRLJsvztz8MSob/Ro0R6FERAq9Bq0/tiEEnb1wPvsYvLv+gzeS jf0ST/tsLNz4FT7mGomzddkDvyOyMhn2cbgylD5MqpFhElQOlY99iS+3k+lQfAomRo uJkLnM6Rt8Zt/0bzPwQM9DU0YlHQnU8lKav0D2pc= Received: by mail-wm1-f44.google.com with SMTP id x15so552312wmj.3 for ; Mon, 24 Jun 2019 13:08:57 -0700 (PDT) X-Gm-Message-State: APjAAAUs92aXO1a89Endi8Ly5A+Zb8/cHskfQvHWCtl2nTuBavFuI1tf j+QGbApOuVwEBT1loI+pzZvPSpCg0audizhLHCi/7Q== X-Google-Smtp-Source: APXvYqyZ4fIE5cdsQv7I/gZrnrFakyNqFBpURFkRXdCRFCL/Nn5A6g099FGLoCCojiN2iaBzq20qxfRFBCC5+SY8tyQ= X-Received: by 2002:a7b:cd84:: with SMTP id y4mr17194362wmj.79.1561406935987; Mon, 24 Jun 2019 13:08:55 -0700 (PDT) MIME-Version: 1.0 References: <20190622000358.19895-1-matthewgarrett@google.com> <20190622000358.19895-24-matthewgarrett@google.com> <739e21b5-9559-d588-3542-bf0bc81de1b2@iogearbox.net> In-Reply-To: From: Andy Lutomirski Date: Mon, 24 Jun 2019 13:08:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V34 23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode To: Matthew Garrett Cc: Daniel Borkmann , James Morris , LSM List , Linux Kernel Mailing List , Linux API , David Howells , Alexei Starovoitov , Network Development , Chun-Yi Lee , Jann Horn , 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 Mon, Jun 24, 2019 at 12:54 PM Matthew Garrett wrote: > > On Mon, Jun 24, 2019 at 8:37 AM Daniel Borkmann wrote: > > > > On 06/22/2019 02:03 AM, Matthew Garrett wrote: > > > From: David Howells > > > > > > There are some bpf functions can be used to read kernel memory: > > > > Nit: that > > Fixed. > > > > bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow > > > > Please explain how bpf_probe_write_user reads kernel memory ... ?! > > Ha. > > > > private keys in kernel memory (e.g. the hibernation image signing key) to > > > be read by an eBPF program and kernel memory to be altered without > > > > ... and while we're at it, also how they allow "kernel memory to be > > altered without restriction". I've been pointing this false statement > > out long ago. > > Yup. How's the following description: > > bpf: Restrict bpf when kernel lockdown is in confidentiality mode > > There are some bpf functions that can be used to read kernel memory and > exfiltrate it to userland: bpf_probe_read, bpf_probe_write_user and > bpf_trace_printk. These could be abused to (eg) allow private > keys in kernel > memory to be leaked. Disable them if the kernel has been locked > down in confidentiality > mode. I'm confused. I understand why we're restricting bpf_probe_read(). Why are we restricting bpf_probe_write_user() and bpf_trace_printk(), though? --Andy