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. Thanks. Tim
