On Wed, Aug 13, 2014 at 2:38 PM, Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote: > On Wed, Aug 13, 2014 at 2:27 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> On 08/13/2014 02:23 PM, Andy Lutomirski wrote: >>> On Wed, Aug 13, 2014 at 2:21 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >>>> One thing about this that may be a serious concern: allowing the user to >>>> control 8 contiguous bytes of kernel memory may be a security hazard. >>> >>> I'm confused. What kind of memory? I can control a lot more than 8 >>> bytes of stack very easily. >>> >>> Or are you concerned about 8 contiguous bytes of *executable* memory? >>> >> >> Yes. Useful for some kinds of ROP custom gadgets. > > I don't get it. What is ROP ? > What is the concern about 8 bytes ? looked it up. too many abbreviations now days. x64 jit spraying was fixed by Eric some time ago, so JIT emitting movabsq doesn't increase attack surface. various movs of 32-bit immediates can be used for 'custom gadget' just as well. Worst case JIT won't be enabled. In classic BPF we allow junk to be stored in used fields of 'struct sock_filter' and so far that wasn't a problem. eBPF is more paranoid regarding verification. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
