On Tue, Jan 08, 2019 at 01:12:45PM -0800, Tim Chen wrote: > On 12/23/18 3:11 PM, Alexei Starovoitov wrote: > > On Fri, Dec 21, 2018 at 09:44:44AM -0800, Tim Chen wrote: > >> + > >> +4. Kernel sandbox attacking kernel > >> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> + > >> +The kernel has support for running user-supplied programs within the > >> +kernel. Specific rules (such as bounds checking) are enforced on these > >> +programs by the kernel to ensure that they do not violate access controls. > >> + > >> +eBPF is a kernel sub-system that uses user-supplied program > >> +to execute JITed untrusted byte code inside the kernel. eBPF is used > >> +for manipulating and examining network packets, examining system call > >> +parameters for sand boxes and other uses. > >> + > >> +A malicious local process could upload and trigger an malicious > >> +eBPF script to the kernel, with the script attacking the kernel > >> +using variant 1 or 2 and reading memory. > > > > Above is not correct. > > The exploit for var2 does not load bpf progs into kernel. > > Instead the bpf interpreter is speculatively executing bpf prog > > that was never loaded. > > Hence CONFIG_BPF_JIT_ALWAYS_ON=y is necessary to make var2 harder > > to exploit. > > Same goes for other in kernel interpreters and state machines. > > > >> + > >> +Necessary Prerequisites: > >> +1. Malicious local process > >> +2. eBPF JIT enabled for unprivileged users, attacking kernel with secrets > >> +on the same machine. > > > > This is not quite correct either. > > Var 1 could have been exploited with and without JIT. > > Also above sounds like that var1 is still exploitable through bpf > > which is not the case. > > > > Alexi, > > Do you have any suggestions on how to rewrite this two paragraphs? You > are probably the best person to update content for this section. how about moving bpf bits out of this doc and placing them under Documentation/bpf/ ? We can create bpf_security.rst there with specdown mitigations, best practices, useful sysctl and config knobs, etc.
