Received: by 10.213.65.68 with SMTP id h4csp2326055imn; Mon, 9 Apr 2018 01:19:54 -0700 (PDT) X-Google-Smtp-Source: AIpwx48ndU8jDv2mwPc7TFt1Qu8TdnMEjkbAOZCoouRKCQAf3bc20pceTyBMO6KlJu5H8uhOLijm X-Received: by 10.98.31.216 with SMTP id l85mr28503883pfj.80.1523261994376; Mon, 09 Apr 2018 01:19:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523261994; cv=none; d=google.com; s=arc-20160816; b=AmWfBE91b7eHFBlgyC43wwRbYWOqQnQhT1rez57830gLfj2Y1mq+P0eSckeZj3Zlia wd5jpcJ4u2o+dru6c9Wu1/BF5nqCUHk2SLzNuill+qLiNuLAjf0oCTwcVUOuONomZ9rF CoNX4rmGHTcyE7STUVYy+p5XoJJIhxEW7jmImmEguvShzgvavb6PP5PotfJK+DU27k/V Rt9QORcIZ48ubvxqblGb1ei2xZb+ARLvW9YFlZvBlQb+lyFbFha9zocTYLjcXpVk6fgr ewhSxv9Xs0ovBv2ZmDsoF11TACbEY6mPH0+Eu9w6BO+7LXNhU7AJbTOb/bY53D693ufl LK9w== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=bqo450n//907qmUsvnv3cJQyNJEMeRysKUgNFJDbNzQ=; b=fmWY2GSfkW58k8Gzl6t+g9SMXXgfVyBdpA3QLvg4a4WBNcnolJFd/uKLRkpACkyd61 8Q3Y5ZLfLUfn66I8UltF9VUd/CmdFaiBjuFzHYGXo18+PenWVegTMj0tsgPNjv8e4gtw gtwixu/sF4dgRLHCNxnTHqXFM4OPqyePRJmNRhXgoxNmap6zMDdQZMvXbYHVoVTe5V65 QobaJPWO5fSFO+HmgNjNGcs20n124x95649qSW3qKdfHw0h31kBSeIBoKaRCLs4kJ6Wy /eu47Wykrpoz2F8NeAZIwC7z7nkwWz16Rxl7OkSpFG5NLINdKU9/26YSeACOuy0PhnnY kiqA== 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 y125si10870801pgy.91.2018.04.09.01.19.15; Mon, 09 Apr 2018 01:19:54 -0700 (PDT) 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 S1752274AbeDIIOb (ORCPT + 99 others); Mon, 9 Apr 2018 04:14:31 -0400 Received: from www62.your-server.de ([213.133.104.62]:38763 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751140AbeDIIO2 (ORCPT ); Mon, 9 Apr 2018 04:14:28 -0400 Received: from [62.202.221.10] (helo=linux.home) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.85_2) (envelope-from ) id 1f5RwO-00028V-QX; Mon, 09 Apr 2018 10:14:16 +0200 Subject: Re: [GIT PULL] Kernel lockdown for secure boot To: Alexei Starovoitov , joeyli Cc: Andy Lutomirski , David Howells , Ard Biesheuvel , James Morris , One Thousand Gnomes , Linus Torvalds , Matthew Garrett , Greg KH , LKML , Justin Forbes , linux-man , LSM List , Linux API , Kees Cook , linux-efi References: <20180408080742.GE7362@linux-l9pv.suse> <20180409034008.dyte7k5kgkbjh5is@ast-mbp.dhcp.thefacebook.com> From: Daniel Borkmann Message-ID: <9040da29-2803-5c00-d47c-ae676a86b65c@iogearbox.net> Date: Mon, 9 Apr 2018 10:14:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20180409034008.dyte7k5kgkbjh5is@ast-mbp.dhcp.thefacebook.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.99.3/24463/Mon Apr 9 06:21:19 2018) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/09/2018 05:40 AM, Alexei Starovoitov wrote: > On Sun, Apr 08, 2018 at 04:07:42PM +0800, joeyli wrote: [...] >>> If the only thing that folks are paranoid about is reading >>> arbitrary kernel memory with bpf_probe_read() helper >>> then preferred patch would be to disable it during verification >>> when in lockdown mode >> >> Sorry for I didn't fully understand your idea... >> Do you mean that using bpf verifier to filter out bpf program that >> uses bpf_probe_read()? > > Take a look bpf_get_trace_printk_proto(). > Similarly we can add bpf_get_probe_read_proto() that > will return NULL if lockdown is on. > Then programs with bpf_probe_read() will be rejected by the verifier. Fully agree with the above. For the two helpers, something like the below would be sufficient to reject progs at verification time. diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index d88e96d..51a6c2e 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -117,6 +117,11 @@ static const struct bpf_func_proto bpf_probe_read_proto = { .arg3_type = ARG_ANYTHING, }; +static const struct bpf_func_proto *bpf_get_probe_read_proto(void) +{ + return kernel_is_locked_down("BPF") ? NULL : &bpf_probe_read_proto; +} + BPF_CALL_3(bpf_probe_write_user, void *, unsafe_ptr, const void *, src, u32, size) { @@ -282,6 +287,9 @@ static const struct bpf_func_proto bpf_trace_printk_proto = { const struct bpf_func_proto *bpf_get_trace_printk_proto(void) { + if (kernel_is_locked_down("BPF")) + return NULL; + /* * this program might be calling bpf_trace_printk, * so allocate per-cpu printk buffers @@ -535,7 +543,7 @@ tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) case BPF_FUNC_map_delete_elem: return &bpf_map_delete_elem_proto; case BPF_FUNC_probe_read: - return &bpf_probe_read_proto; + return bpf_get_probe_read_proto(); case BPF_FUNC_ktime_get_ns: return &bpf_ktime_get_ns_proto; case BPF_FUNC_tail_call: