[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 04 Apr 2018 04:31:46 +0000
From: Matthew Garrett <mjg59@...gle.com>
To: alexei.starovoitov@...il.com
Cc: luto@...nel.org, David Howells <dhowells@...hat.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>, jmorris@...ei.org,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
jforbes@...hat.com, linux-man@...r.kernel.org, jlee@...e.com,
LSM List <linux-security-module@...r.kernel.org>,
linux-api@...r.kernel.org, Kees Cook <keescook@...omium.org>,
linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [GIT PULL] Kernel lockdown for secure boot
On Tue, Apr 3, 2018 at 7:34 PM Alexei Starovoitov <
alexei.starovoitov@...il.com> 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.
> No run-time overhead and android folks will be happy
> that lockdown doesn't break their work.
> They converted out-of-tree networking accounting
> module and corresponding user daemon to use bpf:
https://www.linuxplumbersconf.org/2017/ocw/system/presentations/4791/original/eBPF%20cgroup%20filters%20for%20data%20usage%20accounting%20on%20Android.pdf
An alternative would be to only disable kernel reads if the kernel contains
secrets that aren't supposed to be readable by root. If the keyring is
configured such that root can read everything, it seems like less of a
concern?
Powered by blists - more mailing lists