On Mon, Jun 24, 2019 at 12:54 PM Matthew Garrett <mjg59@xxxxxxxxxx> wrote: > > On Mon, Jun 24, 2019 at 8:37 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > > > On 06/22/2019 02:03 AM, Matthew Garrett wrote: > > > From: David Howells <dhowells@xxxxxxxxxx> > > > > > > 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
