All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: James Morris <jmorris@namei.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Arjan van de Ven <arjan@infradead.org>,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH][RFC] security: constify seq_operations
Date: Tue, 11 Aug 2009 14:36:43 +0000	[thread overview]
Message-ID: <20090811143643.GA15096@us.ibm.com> (raw)
In-Reply-To: <alpine.LRH.2.00.0908112337450.21218@tundra.namei.org>

Quoting James Morris (jmorris@namei.org):
> I think it'd be a good idea to constify more of the various operations 
> structs in the kernel -- our coverage of this is spotty.
> 
> The patch below should provide coverage for all of the eligible 
> seq_operations structs in the kernel.  It's derived from the grsecurity 
> patch (which I was reading and noticed how many of these we're missing).
> 
> It's possible something's been missed, or that there are problems in code 
> which I can't test.  Please review/comment/test.
> 
> If it looks ok, I suggest pushing this via -mm.
> 
> Note that there are quite a few other similar ops to be constified, such 
> as file_operations, so if anyone would like to pitch in, please do so.
> 
> ---
> 
> Subject: [PATCH 1/1] security: constify seq_operations
> 
> Make all seq_operations structs const, to help mitigate
> against revectoring user-triggerable function pointers.
> 
> This is derived from the grsecurity patch, although generated
> from scratch because it's simpler than extracting the changes
> from there.
> 
> Signed-off-by: James Morris <jmorris@namei.org>

I think it's a good idea.

I suppose we could add a script to check for any new
seq_ops structs not constified...  something as simple as
find . -type f -print0 | xargs -0 grep 'struct seq_operations' | grep -v const
Though what you have here hits all of those and more.

Acked-by: Serge Hallyn <serue@us.ibm.com>

thanks,
-serge

WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: James Morris <jmorris@namei.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Arjan van de Ven <arjan@infradead.org>,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH][RFC] security: constify seq_operations
Date: Tue, 11 Aug 2009 09:36:43 -0500	[thread overview]
Message-ID: <20090811143643.GA15096@us.ibm.com> (raw)
In-Reply-To: <alpine.LRH.2.00.0908112337450.21218@tundra.namei.org>

Quoting James Morris (jmorris@namei.org):
> I think it'd be a good idea to constify more of the various operations 
> structs in the kernel -- our coverage of this is spotty.
> 
> The patch below should provide coverage for all of the eligible 
> seq_operations structs in the kernel.  It's derived from the grsecurity 
> patch (which I was reading and noticed how many of these we're missing).
> 
> It's possible something's been missed, or that there are problems in code 
> which I can't test.  Please review/comment/test.
> 
> If it looks ok, I suggest pushing this via -mm.
> 
> Note that there are quite a few other similar ops to be constified, such 
> as file_operations, so if anyone would like to pitch in, please do so.
> 
> ---
> 
> Subject: [PATCH 1/1] security: constify seq_operations
> 
> Make all seq_operations structs const, to help mitigate
> against revectoring user-triggerable function pointers.
> 
> This is derived from the grsecurity patch, although generated
> from scratch because it's simpler than extracting the changes
> from there.
> 
> Signed-off-by: James Morris <jmorris@namei.org>

I think it's a good idea.

I suppose we could add a script to check for any new
seq_ops structs not constified...  something as simple as
find . -type f -print0 | xargs -0 grep 'struct seq_operations' | grep -v const
Though what you have here hits all of those and more.

Acked-by: Serge Hallyn <serue@us.ibm.com>

thanks,
-serge

  reply	other threads:[~2009-08-11 14:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-11 13:52 [PATCH][RFC] security: constify seq_operations James Morris
2009-08-11 13:52 ` James Morris
2009-08-11 14:36 ` Serge E. Hallyn [this message]
2009-08-11 14:36   ` Serge E. Hallyn
2009-08-11 15:32   ` James Morris
2009-08-11 15:32     ` James Morris
2009-08-11 19:47     ` Julia Lawall
2009-08-11 19:47       ` Julia Lawall
2009-08-15  9:15       ` Artem Bityutskiy
2009-08-15  9:15         ` Artem Bityutskiy
2009-08-12  4:28   ` Arjan van de Ven
2009-08-12  4:28     ` Arjan van de Ven
2009-08-12 17:08 ` Casey Schaufler
2009-08-12 17:08   ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090811143643.GA15096@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=hch@infradead.org \
    --cc=jmorris@namei.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.