Re: [uml-devel] skas3(-v3) for 2.4.27 with exec-shield

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

On Friday 17 September 2004 20:54, BlaisorBlade wrote:
> On Thursday 16 September 2004 23:01, Goetz Bock wrote:
> > Hi all,
> >
> > as I've no realy idea about the internal work of the skas patches, I'll
> > have to bother you.
Don't worry.
> > I'd like to run a 2.4.27 kernel with exec-shield patch and skas3, if
> > possible the -v3 version from BlaisorBlade, except that it does not
> > apply :-(

> > There are three conflicts in mm/mprotect.c but i suspect there are more
> > not working sections.
> >
> > The patch seams to mainly change current->mm to mm, after defining
> >
> >     struct mm_struct * mm = vma->vm_mm;
> >
> > unfortunately i've no idea how current-> mm and vma->vm_mm (aka mm)
> > relate. Are they the same?
>
> Not at all; they must be different.

> If you look below, you see that in the old code, sys_mprotect says: "I'm
> acting on current->mm"; the patch wants to be able to pass it any mm_struct
> (and this is done within mm/proc_mm.c), so I had to replace every reference
> to current->mm with a reference to the mm.

Sorry, I did not finish the message.

Actually, the idea is to make that substitution in everything inside 
mm/mprotect.c (but also for all calls invoked by mm/proc_mm.c - 
write_proc_mm(), i.e. mmap and munmap); however, this also means adding one 
more parameter to each of those calls, so I implemented it in a different 
way, the one you see.
I investigated a bit and discovered that if, inside the mm_struct* mm0, I pick 
one vm_area_struct (vma1), then vma1->vm_mm is always equal to mm0. So the 
implementation is the one above.

Also, some general VM info:
- one mm_struct contains all the memory mappings of one process; if you have 
more threads (which share the same memory), they share the mm_struct.
- inside a mm_struct, there are lots of vm_area_struct; when you call mmap() 
in userspace, one new vm_area_struct is created, containing the data to 
represent the created mapping. There are also some other situations in which 
a vm_area_struct is created, however this is enough. Also, a vm_area_struct 
(a VMA) is never shared between two mm_struct.

Also, when you do cat /proc/<aPid>/maps, what you see is a dump of the VMAs of 
that process (the one with <aPid>); each line contains the data of one VMA.

Finally, what the patch does:
- it allows one UML thread (the kernel thread) to do something like 
mmap()/munmap()/mprotect(), except that these calls have effect on the 
userspace thread (the one running the various process); also, it allows this 
process to have various mm_struct; the kernel thread, with PTRACE_SWITCH_MM, 
can make the userspace thread switch from one mm_struct to another (and this 
is done when a different guest process must run).

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel