Re: [RFC 2/2] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation

[Cyrill Gorcunov]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/