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.
next prev parent 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