On Wed, Jul 09, 2014 at 07:53:10AM -0700, Kees Cook wrote: ... > > + > > + /* > > + * Make sure the pairs are ordered. > > + */ > > +#define __prctl_check_order(__map, __m1, __m2) > > \ > > + (unsigned long)__map->__m2 <= (unsigned long)__map->__m1 > > + if (__prctl_check_order(prctl_map, start_code, end_code) || > > + __prctl_check_order(prctl_map, start_data, end_data) || > > + __prctl_check_order(prctl_map, arg_start, arg_end) || > > + __prctl_check_order(prctl_map, env_start, env_end)) > > + goto out; > > +#undef __prctl_check_order > > This approach seems like a good solution given the security concerns > with the earlier approach. I'm still pondering the implications, but > as a minor style note, these macros are locally defined, but also all > take at least a single identical argument in every usage. I would > think it might be easier to read if they just used what they needed to > directly. > > #define __prctl_check_addr_space(__member) \ > ((unsigned long)prctl_map->__member < mmap_max_addr && \ > (unsigned long)prctl_map->__member >= mmap_min_addr) ? 0 : -EINVAL > > #define __prctl_check_vma(__member) \ > find_vma(mm, (unsigned long)prctl_map->__member) ? 0 : -EINVAL > > Also, why change the symantics of the final macro? Seems like that one > can use the same "error |=" style: > > #define __prctl_check_order(__m1, __m2) \ > prctl_map->__m1 < prctl_map->__m2 ? 0 : -EINVAL
Thanks a lot for comments, Kees! I tend to agre, leaving off the @prctl_map variable out of macros should make code also shorter, I'll update that's not the problem. Could you please re-check if I'm not missing something in security aspects when time permits. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
