From: "PaX Team" <pageexec@freemail.hu>
To: Kees Cook <keescook@chromium.org>, Mark Rutland <mark.rutland@arm.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>,
Joe Perches <joe@perches.com>,
Fengguang Wu <fengguang.wu@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Glenn Wurster <gwurster@blackberry.com>
Subject: Re: constification and cocci / kernel build test robot ?
Date: Thu, 01 Sep 2016 16:10:25 +0200 [thread overview]
Message-ID: <57C836D1.25222.4A0B007@pageexec.freemail.hu> (raw)
In-Reply-To: <20160831164119.GA6633@leverpostej>
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.
next prev parent reply other threads:[~2016-09-01 14:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-27 18:59 [PATCH] thermal: fix of_table.cocci warnings Julia Lawall
2016-08-27 19:11 ` constification and cocci / kernel build test robot ? Joe Perches
2016-08-28 9:40 ` Julia Lawall
2016-08-28 13:13 ` Julia Lawall
2016-08-28 17:39 ` Joe Perches
2016-08-28 17:43 ` Julia Lawall
2016-08-30 18:50 ` Kees Cook
2016-08-30 19:23 ` Julia Lawall
2016-08-30 22:15 ` Kees Cook
2016-08-31 5:22 ` Julia Lawall
2016-08-31 10:08 ` Mark Rutland
2016-08-31 14:44 ` Kees Cook
2016-08-31 16:41 ` Mark Rutland
2016-09-01 14:10 ` PaX Team [this message]
2016-08-29 17:00 ` [PATCH] thermal: fix of_table.cocci warnings Bin Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57C836D1.25222.4A0B007@pageexec.freemail.hu \
--to=pageexec@freemail.hu \
--cc=fengguang.wu@intel.com \
--cc=gwurster@blackberry.com \
--cc=joe@perches.com \
--cc=julia.lawall@lip6.fr \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).