[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120203071819.GC1968@moon>
Date: Fri, 3 Feb 2012 11:18:19 +0400
From: Cyrill Gorcunov <gorcunov@...nvz.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org,
Pavel Emelyanov <xemul@...allels.com>,
Serge Hallyn <serge.hallyn@...onical.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Kees Cook <keescook@...omium.org>, Tejun Heo <tj@...nel.org>,
Andrew Vagin <avagin@...nvz.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Alexey Dobriyan <adobriyan@...il.com>,
Andi Kleen <andi@...stfloor.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
Vasiliy Kulikov <segoon@...nwall.com>
Subject: Re: [patch cr 4/4] c/r: prctl: Extend PR_SET_MM to set up more
mm_struct entries
On Thu, Feb 02, 2012 at 03:27:05PM -0800, Andrew Morton wrote:
> On Mon, 30 Jan 2012 18:09:09 +0400
> Cyrill Gorcunov <gorcunov@...nvz.org> wrote:
>
> > After restore we would like the 'ps' command show the command
> > line and evironment exactly the same it was at checkpoint time.
> >
> > So this additional PR_SET_MM_ allow us to do so. Note that
> > these members of mm_struct is rather used for output in
> > procfs, except auxv vector which is used by ld.so mostly.
>
> This changelog is pretty darned hard to understand. Can we have a
> version 2 please?
>
yeah, will update.
...
> > @@ -1790,16 +1779,53 @@ static int prctl_set_mm(int opt, unsigne
> > mm->brk = addr;
> > break;
>
> Here would be a good place to add some nice comments explaining what
> these do. Although I guess that isn't needed if one can get that info
> by typing "man prctl".
>
I started cooking prctl man pages but found hardness to explain some
regular user who has no ideas about kernel internals why do we modify
mm_struct data, still I'm trying.
And I'll add comment here (since having it here in-place allows reader
to not read man page ;)
...
>
> I worry a bit about this. We're giving userspace the ability to modify
> various mm_struct fields. Userspace can already do this via
> exec(elf-file), but perhaps this opens up a way in which userspace can
> newly trigger kernel bugs.
>
At moment there is no more way to modify these fields other than elf
handler, but in future... hard to predict what else there will be
done and where also these fields appear in kernel code. but as i said
at moment this modification is pretty safe and even if one write some
buggy values -- he simply get weird output in /proc/ statistics and
such.
Cyrill
--
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/
Powered by blists - more mailing lists