[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 01 Sep 2016 16:10:25 +0200
From: "PaX Team" <pageexec@...email.hu>
To: Kees Cook <keescook@...omium.org>, Mark Rutland <mark.rutland@....com>
CC: Julia Lawall <julia.lawall@...6.fr>, Joe Perches <joe@...ches.com>,
Fengguang Wu <fengguang.wu@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Glenn Wurster <gwurster@...ckberry.com>
Subject: Re: constification and cocci / kernel build test robot ?
On 31 Aug 2016 at 17:41, Mark Rutland wrote:
> > The plugin marks them actually const, so the const_cast() is needed to
> > "forget" that marking and treat it as a normal variable. (And PaX Team
> > noted that this is the name used in C++ already.)
>
> From having a look around, my understanding is that with C++ this is
> only valid if the underlying object is not const (i.e. it's only valid
> to remove constness from a pointer or reference which had itself added
> constness to a non-const object).
>
> I see that GCC is happy to constant-fold function pointers in const
> objects it has visibility of; example below. Making the objects
> themselves const is bound to lead to fragility (e.g. static inline
> functions in a header behaving differently from related functions in
> another file).
>
> Have I misunderstood something?
it's all correct but it's also not what PaX does for exactly this reason.
instead we only constify types where no global variable instances are accessed
directly. for directly accessed global variables we use __read_only and
pax_open/close_kernel calls. ideally, this should be done for all cases and
then const_cast would no longer be needed however that requires some non-trivial
work on the plugin side.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
