public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Ingo Molnar <mingo@elte.hu>
Cc: Siarhei Liakh <sliakh.lkml@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Arjan van de Ven <arjan@infradead.org>,
	James Morris <jmorris@namei.org>,
	Andrew Morton <akpm@linux-foundation.org>, Andi Kleen <ak@muc.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v5] RO/NX protection for loadable kernel modules
Date: Sat, 11 Jul 2009 20:52:56 +0930	[thread overview]
Message-ID: <200907112052.57174.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090711073037.GA28414@elte.hu>

On Sat, 11 Jul 2009 05:00:37 pm Ingo Molnar wrote:
> Sigh, and now you apply this incomplete and unclean patch. The thing
> is, unpatched upstream kernel/module.c is quite a readability mess
> right now, even on the most trivial level and beyond comments:

Hi Ingo!

    First, thanks for reading this code.  Always useful to annoy you into 
reading my stuff :)

TBH most of those things don't worry me enough to reject patches.  If there 
were other problems, I might ask someone to fix those up too, but I try not to 
post feedback like the one you gave.

>  - Code flow confusion: inconsistent checks for allocation errors
>    within the same function.

Which one were you thinking?

>  - Huge functions that should be broken up. load_module() is 470
>    lines long (!).

It is, but unfortunately there's not a clear point to break it.  Pulling 
unrelated ops into a separate function just to reduce function size is worse 
than the disease (see init/main.c's do_basic_setup() for an example, though 
that file is not as bad as I remember).

>         if (ret) {
>                 /* Update module bounds. */
>                 if ((unsigned long)ret < module_addr_min)
>                         module_addr_min = (unsigned long)ret;
>                 if ((unsigned long)ret + size > module_addr_max)
>                         module_addr_max = (unsigned long)ret + size;
>         }
>         return ret;
>   }
>
>   Can you read that function at a glance? I sure cannot.

Yep, for me this is ugly but clear.

I prefer accessible addresses to be held in void *; the module code is a bit 
borderline, but originally void * was less casts than unsigned long (that may 
well have changed in the last few years tho).

> And i'm sure there's more - this is what 2 minutes of looking
> showed. If we cannot even get the trivial stuff right how can we get
> the more complex stuff right?
>
> _Please_ work on making it more readabe before piling more features
> on it ...

I'm not happy with the module.c code, but not for these reasons.  It just does 
lots of little, bitsy things to load and set up a module, many of which are 
arch-specific hooks, and/or config conditional.

eg. I'd like to split load_module() where it says "Module has moved": this 
would be clean, because before that point "mod" is pointing to the temporary 
version.  But trying it quickly reveals it to be worse than the current code.

Small cleanups are possible, but they're not the ones which would make this 
code really straightforward.

Cheers,
Rusty.

  reply	other threads:[~2009-07-11 11:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-08 23:10 [PATCH v5] RO/NX protection for loadable kernel modules Siarhei Liakh
     [not found] ` <20090710112403.GC3760@elte.hu>
     [not found]   ` <200907111537.03191.rusty@rustcorp.com.au>
2009-07-11  7:30     ` Ingo Molnar
2009-07-11 11:22       ` Rusty Russell [this message]
2009-07-11  8:51     ` Rusty Russell
2009-07-11 15:49       ` Arjan van de Ven
2009-07-12  4:40         ` Rusty Russell
2009-07-12  4:45           ` H. Peter Anvin
2009-07-12  7:45           ` Arjan van de Ven
2009-07-12  9:25             ` Andi Kleen
2009-07-12  9:58             ` Rusty Russell
2009-07-12 15:32               ` Arjan van de Ven
2009-07-12 17:33                 ` Greg KH
2009-07-12 21:58                   ` Arjan van de Ven
2009-07-12 22:14                     ` Greg KH
2009-07-13  9:02                     ` Andi Kleen
2009-07-12 23:21                 ` Rusty Russell
2009-07-13  3:11                   ` Arjan van de Ven
2009-07-12  9:24           ` Andi Kleen
2009-07-13 16:59             ` Roland Dreier
2009-07-13 10:59           ` Jesper Nilsson

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=200907112052.57174.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=ak@muc.de \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sliakh.lkml@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox