Messages in this thread | | | Date | Fri, 2 Mar 2012 00:00:26 +0400 | From | Cyrill Gorcunov <> | Subject | Re: [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file |
| |
On Thu, Mar 01, 2012 at 08:41:20PM +0100, Oleg Nesterov wrote: ... > > Still can't understand. I think you need: > > file = fget(fd); > if (!file) > return -EBADF; > > down_write(&mm->mmap_sem); > if (mm->num_exe_file_vmas) { > fput(mm->exe_file); > mm->exe_file = file; > file = NULL; > } > up_write(&mm->mmap_sem); > > if (!file) > return 0; > > fput(file); > return -ESOMETHING; > > and that is all.
This breaks overall logic of num_exe_file_vmas. What the point to have it at all then? I mean, if there several executable sections in elf file, once loader finish its work we will have num_exe_file_vmas more than 1.
Then the process calls for prctl and replaces own exe_file (I'm talking about possible scenario since for our own tool we know that there will be only one .text section and we're more-less safe in replacing own exe_file, but this interface will be available for everyone who has c/r config entry turned on, so I'm trying to find which negative impact this feature might have, call me paranoid), so once process has replaced own exe_file to something else the code which depends on num_exe_file_vmas become broken.
May not we have a scenario when removed_exe_file_vma is be called somewhere else later, once this prctl finished its work? That's what I fear of.
Cyrill
| |