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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1608310620420.3026@hadrien>
Date:   Wed, 31 Aug 2016 06:22:49 +0100 (IST)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     Kees Cook <keescook@...omium.org>
cc:     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>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: constification and cocci / kernel build test robot ?



On Tue, 30 Aug 2016, Kees Cook wrote:

> On Tue, Aug 30, 2016 at 3:23 PM, Julia Lawall <julia.lawall@...6.fr> wrote:
> >
> >
> > On Tue, 30 Aug 2016, Kees Cook wrote:
> >
> >> On Sun, Aug 28, 2016 at 9:13 AM, Julia Lawall <julia.lawall@...6.fr> wrote:
> >> > [Adding Kees, in case it's of interest]
> >> >
> >> > Below is the list of types of top-level initialized structures and the
> >> > number that are const.  For quicker reading, here are some that are
> >> > sometimes const (numerator), but not always (denominator):
> >> >
> >> > file_operations: 2221/2233
> >> > attribute_group: 447/919
> >> > irq_chip: 1/518
> >> > net_device_ops: 488/498
> >> > regmap_config: 407/447
> >> > dev_pm_ops: 398/415
> >> > clk_ops: 314/386
> >> > resource: 6/385
> >> > seq_operations: 327/328
> >> > snd_pcm_ops: 9/288
> >> >
> >> > and here are the most used ones that are never const at all:
> >> >
> >> > platform_driver: 2943
> >> > platform_device: 2226
> >> > clk_branch: 1131
> >> > i2c_driver: 786
> >> > pci_driver: 781
> >> > omap_hwmod_ocp_if: 670
> >> > omap_hwmod: 582
> >> > notifier_block: 556
> >> > clk: 473
> >> > clk_rcg2: 384
> >> >
> >> > [...]
> >>
> >> The structures that should get the greatest level of attention are
> >> those that contain function pointers. The "constify" gcc plugin from
> >> PaX/Grsecurity does this, but it uses a big hammer: it moves all of
> >> them const even if they receive assignment. To handle this, there is
> >> the concept of an open/close method to gain temporary access to the
> >> structure. For example:
> >>
> >> drivers/cdrom/cdrom.c:
> >>
> >> int register_cdrom(...) {
> >>         ...
> >>         if (!cdo->generic_packet) {
> >>                 pax_open_kernel();
> >>                 const_cast(cdo->generic_packet) = cdrom_dummy_generic_packet;
> >>                 pax_close_kernel();
> >
> > Thanks for the clarification.  The above has to be added to the code
> > manually, or the plugin does it?
>
> Currently, the plugin just warns, and a successful build depends on
> manually adding the open/close logic. For simple cases, the plugin
> could be taught to do this automatically, but some situations are more
> complex.

I guess it would be desirable to avoid this if at all possible. But maybe
it would end up in some library functions, because some drivers would call
them from an init context.

julia