lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140709150604.GN17860@moon.sw.swsoft.com>
Date:	Wed, 9 Jul 2014 19:06:04 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Kees Cook <keescook@...omium.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Tejun Heo <tj@...nel.org>,
	Andrew Vagin <avagin@...nvz.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [RFC 2/2] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ