linux-kernel - Re: [PATCH 28/31] Constify struct super

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]

Date:	Wed, 09 Dec 2009 01:24:34 +0100
From:	Emese Revfy <re.emese@...il.com>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	Alexey Dobriyan <adobriyan@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 28/31] Constify struct super_operations for 2.6.32 v1

Al Viro wrote:
> On Tue, Dec 08, 2009 at 01:06:38AM +0100, Emese Revfy wrote:
> 
>> DEBUG_RODATA catches the unwanted write attempt at runtime whereas
>> my patch will catch it at compile time. I think it's better to detect
>> an error as early as possible.
> 
> Not when the price is readability.  

If constifying the function pointer fields reduces readability,
what would you say for turning then into typedefs, something like this:

typedef int (* super_ops_statfs) (struct dentry *, struct kstatfs *);
struct super_operations {
...
	const super_ops_statfs statfs;
...
};

> Moreover, you *still* are not
> covering the real policy - these suckers should be statically allocated,
> not just never modified.

If the super ops are allocated on the stack then they will be overwritten
during later syscalls and will eventually crash the system on a future
dereference, that is, this kind of problem manifests during development.

If the super ops are allocated by kmalloc/etc, then they will have to be
explicitly initialised by writing to specific fields, my patch would prevent
that.

So in the end the programmer is forced to allocate and initialise super ops
statically.
---
Emese
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/