On Tue, Apr 12, 2005 at 03:31:43AM -0700, [email protected] wrote: > From: Andi Kleen <[email protected]> > > Use a real VMA to map the 32bit vsyscall page [...] > +/* Setup a VMA at program startup for the vsyscall page */ > +int syscall32_setup_pages(struct linux_binprm *bprm, int exstack) > +{ > + int npages = (VSYSCALL32_END - VSYSCALL32_BASE) >> PAGE_SHIFT; > + struct vm_area_struct *vma; > + struct mm_struct *mm = current->mm; > + > + vma = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL); > + if (!vma) > + return -ENOMEM; > + if (security_vm_enough_memory(npages)) { > + kmem_cache_free(vm_area_cachep, vma); > + return -ENOMEM; > + } > + > + memset(vma, 0, sizeof(struct vm_area_struct)); > + /* Could randomize here */ > + vma->vm_start = VSYSCALL32_BASE; > + vma->vm_end = VSYSCALL32_END; > + /* MAYWRITE to allow gdb to COW and set breakpoints */ > + vma->vm_flags = VM_READ|VM_EXEC|VM_MAYREAD|VM_MAYEXEC|VM_MAYEXEC|VM_MAYWRITE; Any reason for VM_MAYEXEC to be specified twice? did you mean something else? Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/
Attachment:
signature.asc
Description: Digital signature
- Follow-Ups:
- Re: [patch 072/198] x86_64: Use a VMA for the 32bit vsyscall
- From: Andi Kleen <[email protected]>
- Re: [patch 072/198] x86_64: Use a VMA for the 32bit vsyscall
- References:
- Prev by Date: Re: Processes stuck on D state on Dual Opteron
- Next by Date: Re: [RFC] FUSE permission modell (Was: fuse review bits)
- Previous by thread: [patch 072/198] x86_64: Use a VMA for the 32bit vsyscall
- Next by thread: Re: [patch 072/198] x86_64: Use a VMA for the 32bit vsyscall
- Index(es):