linux-kernel - Re: constification and cocci / kernel build test robot ?

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] [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.