From: Pavel Emelyanov <xemul@parallels.com>
To: Kees Cook <keescook@chromium.org>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH c/r -mm] c/r: prctl: Simplify PR_SET_MM on mm::code/data assignment
Date: Tue, 17 Apr 2012 20:32:06 +0400 [thread overview]
Message-ID: <4F8D9B06.109@parallels.com> (raw)
In-Reply-To: <CAGXu5jKHZSXXxWQdkQ2d0-soaUkQys85XjQ1M2Fx_hg5vTrs2Q@mail.gmail.com>
On 04/17/2012 08:26 PM, Kees Cook wrote:
> On Mon, Apr 16, 2012 at 3:55 PM, Cyrill Gorcunov <gorcunov@openvz.org> wrote:
>> The mm::start_code, end_code, start_data, end_data members
>> are set during startup of executable file and are not changed
>> after.
>>
>> But the program itself might map new executable or/and data areas in
>> time so the original values written into mm fields mentioned above
>> might not have correspond VMA area at all, thus if one try to
>> use this prctl codes without underlied VMA, the error will be
>> returned.
>
> Hrm, what is the utility of these fields then? If they're not "real",
> should the kernel even bother tracking it at all? (Or, should it be
> fixed to actually do something useful?)
As far as I see these values are used by aout binfmt core-dumping code
and in flat relocations load. Elf doesn't read either of them, just loads.
> -Kees
>
next prev parent reply other threads:[~2012-04-17 16:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-16 22:55 [PATCH c/r -mm] c/r: prctl: Simplify PR_SET_MM on mm::code/data assignment Cyrill Gorcunov
2012-04-17 16:26 ` Kees Cook
2012-04-17 16:28 ` Cyrill Gorcunov
2012-04-17 16:32 ` Pavel Emelyanov [this message]
2012-04-17 16:48 ` Cyrill Gorcunov
2012-04-17 18:22 ` Kees Cook
2012-04-17 19:19 ` Cyrill Gorcunov
2012-04-17 19:49 ` Cyrill Gorcunov
2012-04-17 19:53 ` Kees Cook
2012-04-20 14:12 ` Serge Hallyn
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=4F8D9B06.109@parallels.com \
--to=xemul@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=gorcunov@openvz.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serge.hallyn@canonical.com \
--cc=tj@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.