Re: [RFC 1/1] proc: constify seq_operations

[Richard Weinberger]

On Tue, Jul 1, 2014 at 10:17 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Mon, Jun 30, 2014 at 01:39:39PM -0700, Andrew Morton wrote:
>> On Mon, 30 Jun 2014 21:03:17 +0200 Fabian Frederick <fabf@xxxxxxxxx> wrote:
>>
>> > proc_uid_seq_operations, proc_gid_seq_operations and proc_projid_seq_operations
>> > are only called in proc_id_map_open with seq_open as
>> > const struct seq_operations so we can constify the 3 structures and update
>> > proc_id_map_open prototype.
>>
>> There are an absolutely enormous number of places where we could
>> constify things.  For sheer sanity's sake I'm not inclined to churn the
>> code in this way unless a patch provides some sort of runtime benefit.
>> And this particular patch doesn't appear to change the generated code
>> at all.
>
> Unlike a lot of the cleanup patches which provide no benefit at all
> constifying op vectors moves them from .text to .data which is not
> marked executable and thus reduce the attack vector for kernel exploits.
>
> So I defintively like to see these much more than a lot of the other
> things filling up the lists.

BTW: Daniel Walter and I are currently working with grsec's constify gcc plugin.
This plugin automatically makes structs const which contain only
function pointers.
Our goal is to bring it mainline. We cannot enable it by default as
many gcc toolchains
have plugin support disabled. But at least as tool in tools/ it would
be handy to create
constify patches automatically...

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/