From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932993AbcIAOuf (ORCPT <rfc822;w@1wt.eu>);
        Thu, 1 Sep 2016 10:50:35 -0400
Received: from r00tworld.com ([212.85.137.150]:60686 "EHLO r00tworld.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932469AbcIAOue (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 1 Sep 2016 10:50:34 -0400
X-Greylist: delayed 2343 seconds by postgrey-1.27 at vger.kernel.org; Thu, 01 Sep 2016 10:50:34 EDT
From: "PaX Team" <pageexec@freemail.hu>
To: Kees Cook <keescook@chromium.org>, Mark Rutland <mark.rutland@arm.com>
Date: Thu, 01 Sep 2016 16:10:25 +0200
MIME-Version: 1.0
Subject: Re: constification and cocci / kernel build test robot ?
Reply-to: pageexec@freemail.hu
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>
Message-ID: <57C836D1.25222.4A0B007@pageexec.freemail.hu>
In-reply-to: <20160831164119.GA6633@leverpostej>
References: <alpine.DEB.2.10.1608272058090.3363@hadrien>, <CAGXu5jLUunTNw8LoNQdSoP2NU=SxzKDmXExEBeg-vSeOxk4iYA@mail.gmail.com>, <20160831164119.GA6633@leverpostej>
X-mailer: Pegasus Mail for Windows (4.72.572)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.12 (r00tworld.com [212.85.137.150]); Thu, 01 Sep 2016 16:10:28 +0200 (CEST)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.