Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756812AbdDFMk1 (ORCPT ); Thu, 6 Apr 2017 08:40:27 -0400 Received: from mail-io0-f177.google.com ([209.85.223.177]:35167 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754772AbdDFMkV (ORCPT ); Thu, 6 Apr 2017 08:40:21 -0400 MIME-Version: 1.0 In-Reply-To: <20170406122907.GA53880@ast-mbp.thefacebook.com> References: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk> <149142344547.5101.4518618716303032193.stgit@warthog.procyon.org.uk> <20170406122907.GA53880@ast-mbp.thefacebook.com> From: Ard Biesheuvel Date: Thu, 6 Apr 2017 13:40:20 +0100 Message-ID: Subject: Re: [PATCH 20/24] bpf: Restrict kernel image access functions when the kernel is locked down To: Alexei Starovoitov Cc: David Howells , "linux-kernel@vger.kernel.org" , "linux-efi@vger.kernel.org" , One Thousand Gnomes , "" , Chun-Yi Lee , linux-security-module , keyrings@vger.kernel.org, "gregkh@linuxfoundation.org" , Matthew Garrett Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1868 Lines: 47 On 6 April 2017 at 13:29, Alexei Starovoitov wrote: > On Wed, Apr 05, 2017 at 09:17:25PM +0100, David Howells wrote: >> From: Chun-Yi Lee >> >> There are some bpf functions can be used to read kernel memory: >> bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow >> private keys in kernel memory (e.g. the hibernation image signing key) to >> be read by an eBPF program. Prohibit those functions when the kernel is >> locked down. >> >> Signed-off-by: Chun-Yi Lee >> Signed-off-by: David Howells >> cc: netdev@vger.kernel.org >> --- >> >> kernel/trace/bpf_trace.c | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c >> index cee9802cf3e0..7fde851f207b 100644 >> --- a/kernel/trace/bpf_trace.c >> +++ b/kernel/trace/bpf_trace.c >> @@ -65,6 +65,11 @@ BPF_CALL_3(bpf_probe_read, void *, dst, u32, size, const void *, unsafe_ptr) >> { >> int ret; >> >> + if (kernel_is_locked_down()) { >> + memset(dst, 0, size); >> + return -EPERM; >> + } > > this will obviously break the program. How about disabling loading tracing > programs during the lockdown completely? > > Also is there a description of what this lockdown trying to accomplish? > The cover letter is scarce in details. > This is a very good point, and this is actually feedback that was given (by Alan Cox, iirc) the last time this series was circulated. This series is a mixed bag of patches that all look like they improve 'security' in one way or the other. But what is lacking is a coherent view on the threat model, and to what extent all these patches reduce the vulnerability to such threats. Without that, these patches do very little beyond giving a false sense of security, imo.