On 7/28/20 6:38 AM, ebied...@xmission.com wrote:
> Anthony Yznaga <anthony.yzn...@oracle.com> writes:
>
>> A vma with the VM_EXEC_KEEP flag is preserved across exec. For anonymous
>> vmas only. For safety, overlap with fixed address VMAs created in the new
>> mm during exec (e.g. the stack and elf load segments) is not permitted and
>> will cause the exec to fail.
>> (We are studying how to guarantee there are no conflicts. Comments welcome.)
>>
>> diff --git a/fs/exec.c b/fs/exec.c
>> index 262112e5f9f8..1de09c4eef00 100644
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -1069,6 +1069,20 @@ ssize_t read_code(struct file *file, unsigned long
>> addr, loff_t pos, size_t len)
>> EXPORT_SYMBOL(read_code);
>> #endif
>>
>> +static int vma_dup_some(struct mm_struct *old_mm, struct mm_struct *new_mm)
>> +{
>> + struct vm_area_struct *vma;
>> + int ret;
>> +
>> + for (vma = old_mm->mmap; vma; vma = vma->vm_next)
>> + if (vma->vm_flags & VM_EXEC_KEEP) {
>> + ret = vma_dup(vma, new_mm);
>> + if (ret)
>> + return ret;
>> + }
>> + return 0;
>> +}
>> +
>> /*
>> * Maps the mm_struct mm into the current task struct.
>> * On success, this function returns with the mutex
>> @@ -1104,6 +1118,12 @@ static int exec_mmap(struct mm_struct *mm)
>> mutex_unlock(&tsk->signal->exec_update_mutex);
>> return -EINTR;
>> }
>> + ret = vma_dup_some(old_mm, mm);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Ouch! An unconditional loop through all of the vmas of the execing
> process, just in case there is a VM_EXEC_KEEP vma.
>
> I know we already walk the list in exit_mmap, but I get the feeling this
> will slow exec down when this feature is not enabled, especially when
> a process with a lot of vmas is calling exec.
Patch 4 changes this to only call vma_dup_some() if the new
binary has opted in to accepting preserved memory.
Anthony
>
>
>> + if (ret) {
>> + mmap_read_unlock(old_mm);
>> + mutex_unlock(&tsk->signal->exec_update_mutex);
>> + return ret;
>> + }
>> }
>>
>> task_lock(tsk);
