From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Pavel Emelianov <xemul@parallels.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Matt Helsley <matthltc@us.ibm.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 3.5] c/r: prctl: less paranoid prctl_set_mm_exe_file()
Date: Sat, 16 Jun 2012 13:42:23 +0400 [thread overview]
Message-ID: <4FDC54FF.3020305@openvz.org> (raw)
In-Reply-To: <20120616091712.GA2021@moon>
Cyrill Gorcunov wrote:
> On Sat, Jun 16, 2012 at 01:06:46PM +0400, Cyrill Gorcunov wrote:
>> On Sat, Jun 16, 2012 at 12:51:04PM +0400, Konstantin Khlebnikov wrote:
>>> "no other files mapped" requirement from my previous patch
>>> (c/r: prctl: update prctl_set_mm_exe_file() after mm->num_exe_file_vmas removal)
>>> is too paranoid, it forbids operation even if there mapped one shared-anon vma.
>>>
>>> Let's check that current mm->exe_file already unmapped, in this case exe_file
>>> symlink already outdated and its changing is reasonable.
>>>
>>> Plus, this patch fixes exit code in case operation success.
>>>
>>> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org>
>>> Reported-by: Cyrill Gorcunov<gorcunov@openvz.org>
>>> Cc: Oleg Nesterov<oleg@redhat.com>
>>> Cc: Matt Helsley<matthltc@us.ibm.com>
>>> Cc: Kees Cook<keescook@chromium.org>
>>> Cc: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>>> Cc: Tejun Heo<tj@kernel.org>
>>> Cc: Pavel Emelyanov<xemul@parallels.com>
>>> ---
>>
>> Ack! Thanks again, Konstantin!
>
> Side note: there is a little nit with this patch actually,
> because while when we do c/r we do "right things" and unmap
> all vm-executable mappings before we set up new exe_file. But
> we can't guarantee that some brave soul would not setup
> new exe-file just for it's own, then what we migh have
>
> - mm::exe_file set up and points to some file, moreover num_exe_file_vmas might be> 1
> - application calls for prctl_set_mm_exe_file
> - set_mm_exe_file(mm, exe_file) called, and it drops num_exe_file_vmas to 0
> - finally application might call for removed_exe_file_vma
>
> void removed_exe_file_vma(struct mm_struct *mm)
> {
> mm->num_exe_file_vmas--;
> if ((mm->num_exe_file_vmas == 0)&& mm->exe_file) {
> fput(mm->exe_file);
> mm->exe_file = NULL;
> }
>
> }
>
> and it does _not_ test for num_exe_file_vmas being 0 before doing decrement,
> thus we get inconsistency in counter.
No, removed_exe_file_vma() is called only for vma with VM_EXECUTABLE flag,
there no way to get such vma other than sys_execve().
And this brave soul cannot call prctl_set_mm_exe_file() successfully,
just because for vma with VM_EXECUTABLE flag vma->vm_file == mm->exe_file.
Anyway, I plan to get rid of mm->num_exe_file_vmas and VM_EXECUTABLE.
>
> Cyrill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Pavel Emelianov <xemul@parallels.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Matt Helsley <matthltc@us.ibm.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 3.5] c/r: prctl: less paranoid prctl_set_mm_exe_file()
Date: Sat, 16 Jun 2012 13:42:23 +0400 [thread overview]
Message-ID: <4FDC54FF.3020305@openvz.org> (raw)
In-Reply-To: <20120616091712.GA2021@moon>
Cyrill Gorcunov wrote:
> On Sat, Jun 16, 2012 at 01:06:46PM +0400, Cyrill Gorcunov wrote:
>> On Sat, Jun 16, 2012 at 12:51:04PM +0400, Konstantin Khlebnikov wrote:
>>> "no other files mapped" requirement from my previous patch
>>> (c/r: prctl: update prctl_set_mm_exe_file() after mm->num_exe_file_vmas removal)
>>> is too paranoid, it forbids operation even if there mapped one shared-anon vma.
>>>
>>> Let's check that current mm->exe_file already unmapped, in this case exe_file
>>> symlink already outdated and its changing is reasonable.
>>>
>>> Plus, this patch fixes exit code in case operation success.
>>>
>>> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org>
>>> Reported-by: Cyrill Gorcunov<gorcunov@openvz.org>
>>> Cc: Oleg Nesterov<oleg@redhat.com>
>>> Cc: Matt Helsley<matthltc@us.ibm.com>
>>> Cc: Kees Cook<keescook@chromium.org>
>>> Cc: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>>> Cc: Tejun Heo<tj@kernel.org>
>>> Cc: Pavel Emelyanov<xemul@parallels.com>
>>> ---
>>
>> Ack! Thanks again, Konstantin!
>
> Side note: there is a little nit with this patch actually,
> because while when we do c/r we do "right things" and unmap
> all vm-executable mappings before we set up new exe_file. But
> we can't guarantee that some brave soul would not setup
> new exe-file just for it's own, then what we migh have
>
> - mm::exe_file set up and points to some file, moreover num_exe_file_vmas might be> 1
> - application calls for prctl_set_mm_exe_file
> - set_mm_exe_file(mm, exe_file) called, and it drops num_exe_file_vmas to 0
> - finally application might call for removed_exe_file_vma
>
> void removed_exe_file_vma(struct mm_struct *mm)
> {
> mm->num_exe_file_vmas--;
> if ((mm->num_exe_file_vmas == 0)&& mm->exe_file) {
> fput(mm->exe_file);
> mm->exe_file = NULL;
> }
>
> }
>
> and it does _not_ test for num_exe_file_vmas being 0 before doing decrement,
> thus we get inconsistency in counter.
No, removed_exe_file_vma() is called only for vma with VM_EXECUTABLE flag,
there no way to get such vma other than sys_execve().
And this brave soul cannot call prctl_set_mm_exe_file() successfully,
just because for vma with VM_EXECUTABLE flag vma->vm_file == mm->exe_file.
Anyway, I plan to get rid of mm->num_exe_file_vmas and VM_EXECUTABLE.
>
> Cyrill
next prev parent reply other threads:[~2012-06-16 9:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-16 8:51 [PATCH 3.5] c/r: prctl: less paranoid prctl_set_mm_exe_file() Konstantin Khlebnikov
2012-06-16 8:51 ` Konstantin Khlebnikov
2012-06-16 9:01 ` Cyrill Gorcunov
2012-06-16 9:01 ` Cyrill Gorcunov
2012-06-16 9:06 ` Cyrill Gorcunov
2012-06-16 9:06 ` Cyrill Gorcunov
2012-06-16 9:17 ` Cyrill Gorcunov
2012-06-16 9:17 ` Cyrill Gorcunov
2012-06-16 9:42 ` Konstantin Khlebnikov [this message]
2012-06-16 9:42 ` Konstantin Khlebnikov
2012-06-16 9:47 ` Cyrill Gorcunov
2012-06-16 9:47 ` Cyrill Gorcunov
2012-06-16 15:38 ` Konstantin Khlebnikov
2012-06-16 15:38 ` Konstantin Khlebnikov
2012-06-16 15:44 ` Cyrill Gorcunov
2012-06-16 15:44 ` Cyrill Gorcunov
2012-06-18 8:58 ` Cyrill Gorcunov
2012-06-18 8:58 ` Cyrill Gorcunov
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=4FDC54FF.3020305@openvz.org \
--to=khlebnikov@openvz.org \
--cc=akpm@linux-foundation.org \
--cc=gorcunov@openvz.org \
--cc=keescook@chromium.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthltc@us.ibm.com \
--cc=oleg@redhat.com \
--cc=tj@kernel.org \
--cc=xemul@parallels.com \
/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.