From: Ian R. <ian...@ma...> - 2005-05-04 09:27:03
|
Hi, I'm relatively new to this but I've not found any information in the FAQ... What I'm hoping to do is to use SKAS to create a second address space I can, map, unmap, peek and poke from the first. The reason for this is to allow an emulator to live in the first address space and the emulated data... to live in the second. I hope to be able to access the second by altering the i386 selector value. If I am successful in this I will put the information available to all on my website or the uml wiki... I was wondering if anyone already had some code to do this or if someone has an strace of the calls involved or failing that any advice/suggestions/... Many thanks, Ian Rogers |
From: Jeff D. <jd...@ad...> - 2005-05-04 13:31:58
|
On Wed, May 04, 2005 at 10:28:28AM +0100, Ian Rogers wrote: > What I'm hoping to do is to use SKAS to create a second address > space I can, map, unmap, peek and poke from the first. The reason for > this is to allow an emulator to live in the first address space and the > emulated data... to live in the second. UML obviously does this. Look at arch/um/kernel/skas/mem_user.c for the basic primitives. The creation and destruction of address spaces is done in arch/um/kernel/skas/mmu.c. > I hope to be able to access the > second by altering the i386 selector value. What's the i386 selector value? Jeff |
From: Ian R. <ian...@ma...> - 2005-05-04 14:48:45
|
Jeff Dike wrote: >On Wed, May 04, 2005 at 10:28:28AM +0100, Ian Rogers wrote: > > >>What I'm hoping to do is to use SKAS to create a second address >>space I can, map, unmap, peek and poke from the first. The reason for >>this is to allow an emulator to live in the first address space and the >>emulated data... to live in the second. >> >> > >UML obviously does this. Look at arch/um/kernel/skas/mem_user.c for the >basic primitives. The creation and destruction of address spaces is done >in arch/um/kernel/skas/mmu.c. > > I've had a play with a simple test, but I need to work further on it. mem_user.c seems clear enough but I am slightly baffled by what is happening with the file descriptors in mmu.c. > > >>I hope to be able to access the >>second by altering the i386 selector value. >> >> > >What's the i386 selector value? > > I hope, for example, to set LDT 0 to point to the second address space. I can then swap the value of 7 (index 0, LDT, ring 3) into fs or gs whenever I hope to address the second address space. I can do similar code with modify_ldt but I'm restricted to using mmap to allocate memory and therefore I don't get a fully addressable 4gb address space. Thanks for your help, Ian Rogers |
From: Blaisorblade <bla...@ya...> - 2005-05-04 19:07:18
|
On Wednesday 04 May 2005 16:49, Ian Rogers wrote: > Jeff Dike wrote: > >On Wed, May 04, 2005 at 10:28:28AM +0100, Ian Rogers wrote: > >>What I'm hoping to do is to use SKAS to create a second address > >>space I can, map, unmap, peek and poke from the first. The reason for > >>this is to allow an emulator to live in the first address space and the > >>emulated data... to live in the second. > > > >UML obviously does this. Look at arch/um/kernel/skas/mem_user.c for the > >basic primitives. The creation and destruction of address spaces is done > >in arch/um/kernel/skas/mmu.c. > > I've had a play with a simple test, but I need to work further on it. > mem_user.c seems clear enough but I am slightly baffled by what is > happening with the file descriptors in mmu.c. > > >>I hope to be able to access the > >>second by altering the i386 selector value. > > > >What's the i386 selector value? > > I hope, for example, to set LDT 0 to point to the second address space. > I can then swap the value of 7 (index 0, LDT, ring 3) into fs or gs > whenever I hope to address the second address space. I can do similar > code with modify_ldt but I'm restricted to using mmap to allocate memory > and therefore I don't get a fully addressable 4gb address space. You'll never get that, sadly, because the upper 1G is used by the kernel itself... This can be achieved on x86_64, even with 32bit binaries (if they are run with the right emulation). -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Ian R. <ian...@ma...> - 2005-05-05 17:02:33
Attachments:
skas_test.c
|
Hi, I've attached the test/example I'm working on to create and manipulate address spaces uses skas - as I want to allow an emulator to. There are a few missing functions (that can be pretty much cloned from mem_user.c) and I've not worked out how to calculate the descriptor value yet. Please could you have a look and suggest how to create the descriptor value and why when I look in /proc/<pid>/maps I can't see the asid_mmap that's being done as part of the test. Many thanks, Ian Rogers |
From: Blaisorblade <bla...@ya...> - 2005-05-07 15:34:39
Attachments:
skas_test.c
|
On Thursday 05 May 2005 19:03, Ian Rogers wrote: > Hi, > > I've attached the test/example I'm working on to create and manipulate > address spaces uses skas - as I want to allow an emulator to. There are > a few missing functions (that can be pretty much cloned from mem_user.c) > and I've not worked out how to calculate the descriptor value yet. > Please could you have a look and suggest how to create the descriptor > value and why when I look in /proc/<pid>/maps I can't see the asid_mmap > that's being done as part of the test. Because you didn't switch the child to use the new MM. The MMAP you do is not related in any way to the child, because you don't pass in the param, right? Instead, it's related to the mm_fd you open. In fact, in the code attached (which is a more working example, I didn't go so far to making sure that the child actually works) I've used PTRACE_SWITCH_MM too. And moved mm_fd to inside AdressSpace, in place of ->descriptor. The included "cat /proc/<pid>/maps" shows that it works. The child should be almost to the point of running well (maybe it already does), though I've no way to make sure of that (I'll have it either to a syscall to be intercepted from the parent or write a value in the memory, or do an inline syscall). I'd also avoid deleting the file to examine it later. Bye -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Jeff D. <jd...@ad...> - 2005-05-07 04:05:03
|
On Thu, May 05, 2005 at 06:03:53PM +0100, Ian Rogers wrote: > I've attached the test/example I'm working on to create and manipulate > address spaces uses skas - as I want to allow an emulator to. There are > a few missing functions (that can be pretty much cloned from mem_user.c) > and I've not worked out how to calculate the descriptor value yet. > Please could you have a look and suggest how to create the descriptor > value and why when I look in /proc/<pid>/maps I can't see the asid_mmap > that's being done as part of the test. Just one little point that would seem to indicate a lack of understanding. You seem to be interested in manipulating many address spaces, but you have a global mm_fd which you open ones, and on which all operations happen. Opening /proc/mm gives you a handle to an address space. If you want two new address spaces, you open it twice. You close one when you don't need the address space any more. Why are you fixated on descriptor values? At this level, that's something you just don't care about. Jeff |
From: Ian R. <ian...@ma...> - 2005-05-07 20:32:04
|
Jeff Dike wrote: > Just one little point that would seem to indicate a lack of understanding. > >You seem to be interested in manipulating many address spaces, but you >have a global mm_fd which you open ones, and on which all operations happen. > >Opening /proc/mm gives you a handle to an address space. If you want two >new address spaces, you open it twice. You close one when you don't need >the address space any more. > > Thanks, there's a lack of documentation so the purpose of the example is to try to determine this kind of information. >Why are you fixated on descriptor values? At this level, that's something >you just don't care about. > > In an emulator the peek and poke routines will be inlined into the dynamically generated code. I'm essentially after a multi-segment model. I want CS/DS/ES to be in the same flat address space. This means the generated code and any spill/fill of register value code will be in the controlling address space, I want to then address the second address space/segment by just using a segment over-ride. Thanks for the help, Ian Rogers |
From: Blaisorblade <bla...@ya...> - 2005-05-08 17:12:22
|
On Saturday 07 May 2005 22:31, Ian Rogers wrote: > Jeff Dike wrote: > > Just one little point that would seem to indicate a lack of > > understanding. > > > >You seem to be interested in manipulating many address spaces, but you > >have a global mm_fd which you open ones, and on which all operations > > happen. > > > >Opening /proc/mm gives you a handle to an address space. If you want two > >new address spaces, you open it twice. You close one when you don't need > >the address space any more. > > Thanks, there's a lack of documentation so the purpose of the example is > to try to determine this kind of information. > > >Why are you fixated on descriptor values? At this level, that's something > >you just don't care about. > > In an emulator the peek and poke routines will be inlined into the > dynamically generated code. I'm essentially after a multi-segment model. > I want CS/DS/ES to be in the same flat address space. This means the > generated code and any spill/fill of register value code will be in the > controlling address space, I want to then address the second address > space/segment by just using a segment over-ride. Hmm, no, that's not what SKAS allows. It simply allows to switch to *another* address space. Yes, you can make arbitrary mmaps, so to replicate the original address space and add some other maps, that you access even through %fs if you want. But that's nothing special to SKAS; the advantage it gives is that: a) the parent can easily alter the child's address space (not the original one it inherits at startup, but only the newly created one). b) the parent can switch the child's current address space through PTRACE_SWITCH_MM (this could be emulated with running many childs). Now, the example almost work. The child can execute the syscalls, even if the verification of the datas it gets is currently failing (I'll be verifying that later). The main problem yesterday's version had was that the mmap's had a offset of 0, since the asid_mmap() loops will always stop at the first entry of AddressSpaces[ASID].map_info, which had a 0 offset. Currently I set the offset equal to the virtual address it's mapped to. Thanks a lot for posting the original version: the finished one will be very useful for the testing of SKAS for x86-64, to debug it and get it working soon. Bye -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Ian R. <ian...@ma...> - 2005-05-08 18:10:16
|
Blaisorblade wrote: >Hmm, no, that's not what SKAS allows. It simply allows to switch to *another* >address space. Yes, you can make arbitrary mmaps, so to replicate the >original address space and add some other maps, that you access even through >%fs if you want. > >But that's nothing special to SKAS; the advantage it gives is that: >a) the parent can easily alter the child's address space (not the original one >it inherits at startup, but only the newly created one). >b) the parent can switch the child's current address space through >PTRACE_SWITCH_MM (this could be emulated with running many childs). > > Thanks. I will implment an emulator through this mechanism. My current mechanism performs: loadByte(addr) { pte = addr >> 12; offset = addr & 0xFFF; result = memory[ptr][offset] } you can imagine the store... mechanisms. Obviously the cost of the ptrace calls is going to be a slow down compared to this. I hope to look into creating a patch to allow multiple segments in a linux process. So an extension to skas on i386 and I can get my %fs wish :-) btw: a similar thing should be possible on PowerPC given that segmentation can be disabled for either or both the instruction and data cache. It would be neat to wrap this up in a module for the performance improvement of emulators. >Now, the example almost work. The child can execute the syscalls, even if the >verification of the datas it gets is currently failing (I'll be verifying >that later). > >The main problem yesterday's version had was that the mmap's had a offset of >0, since the asid_mmap() loops will always stop at the first entry of >AddressSpaces[ASID].map_info, which had a 0 offset. Currently I set the >offset equal to the virtual address it's mapped to. > >Thanks a lot for posting the original version: the finished one will be very >useful for the testing of SKAS for x86-64, to debug it and get it working >soon. Bye > > Glad it was useful and thanks for your help - it's taught me what to do for my emulator code. I hope I can post some more things back in the future. Would the multi-segment stuff be useful for more people? Is there an obvious reason to avoid multi-segments? Regards, Ian Rogers |
From: Blaisorblade <bla...@ya...> - 2005-05-09 15:19:49
|
On Sunday 08 May 2005 20:09, Ian Rogers wrote: > Blaisorblade wrote: > Thanks. I will implment an emulator through this mechanism. My current > mechanism performs: > > loadByte(addr) { > pte = addr >> 12; > offset = addr & 0xFFF; > result = memory[ptr][offset] > } Ok, memory is a square array. > you can imagine the store... mechanisms. Obviously the cost of the > ptrace calls is going to be a slow down compared to this. Well, if it's done only at setup, ok. However, can you please explain to me why it isn't possible to do it without SKAS? > I hope to look into creating a patch to allow multiple segments in a > linux process. So an extension to skas on i386 and I can get my %fs wish > :-) Well, it should be already doable in SKAS, with PTRACE_LDT (which relates to modify_ldt() the same way that writing DO_MMAP relates to mmap()). Then, after *setting* an appropriate descriptor in %fs (with PTRACE_POKEUSR if you need), you're done. > btw: a similar thing should be possible on PowerPC given that > segmentation can be disabled for either or both the instruction and data > cache. It would be neat to wrap this up in a module for the performance > improvement of emulators. > Glad it was useful and thanks for your help - it's taught me what to do > for my emulator code. I hope I can post some more things back in the > future. Would the multi-segment stuff be useful for more people? Is > there an obvious reason to avoid multi-segments? Well, I've proposed some time ago to use segmentation for UML, but the proposal was dropped "because an access through segmentation is a little slower". Quite frankly, I'm quite unconvinced (because any access passes through segmentation, even if normally segments have a 0 base and a disabled limit); beyond, Xen uses segmentation in the same way that I was proposing for UML, IIRC. -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Ian R. <ian...@ma...> - 2005-05-09 18:08:08
|
Hi, Thanks for the help and I'm feeling encouraged again to try this through skas. I still have some thoughts though. >>I hope to look into creating a patch to allow multiple segments in a >>linux process. So an extension to skas on i386 and I can get my %fs wish >>:-) >> >> >Well, it should be already doable in SKAS, with PTRACE_LDT (which relates to >modify_ldt() the same way that writing DO_MMAP relates to mmap()). Then, >after *setting* an appropriate descriptor in %fs (with PTRACE_POKEUSR if you >need), you're done. > > The LDT will give me a base address for the linear address used by the user process (I imagine this will be 0), but it won't do anything about the page table set up. I believe, the process may not work as the linear address can only be 32-bit. I thought there were extensions around this but it seems not. What I'd like would look like "Figure 3-28. Memory Management Convention That Assigns a Page Table to Each Segment" in **"IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide". I think on a 32-bit machine to access multiple 4GB segments isn't possible, CR3 (PDBR) is shared by all segments and so the PDE's must just carve up the 4GB linear address space. It would be nice if CR3 (PDBR) were part of the selector. I could have more success on a 64bit machine...** >Well, I've proposed some time ago to use segmentation for UML, but the >proposal was dropped "because an access through segmentation is a little >slower". > >Quite frankly, I'm quite unconvinced (because any access passes through >segmentation, even if normally segments have a 0 base and a disabled limit); >beyond, Xen uses segmentation in the same way that I was proposing for UML, >IIRC. > > I agree. The mechanism can be tested out and then reverted if it is hurting performance. Thanks again for the help and examples, Ian Rogers |