(implementation idea) Re: uml and nonstandard memory splits?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Jason Lunz
Quoted 8 lines · Jeff Dike
You can make some progress by disabling
CONFIG_MODE_TT- that will cause UML to load at a normal address rather than the0xa0000000thatCONFIG_MODE_TTwill force.That should get you to the point of trying to run init.
Since you have skas3, my guess is that UML will be fine at that point.
Quoted 8 lines
Quoted 4 lines
On a non-skas3 host, it will run in skas0 mode, and will expect to be able to map a couple of pages at the top of the process address space (hardcoded to
0xbfffe000and0xbffff000). These offsets would need to be calculated based on the host's split in order for skas0 to work.So I guess getting a 2.4 uml to work on any split other than 1G/3G is pretty unlikely. Oh well, I already knew 2.4 was on its way out. So this might be the thing that really forces me to use 2.6.
No, that's wrong - what David Lang described:
Quoted 3 lines
I don't know about other non-standard memory configs, but there is an explicit config option when compiling a uml kernel to support the 2G/2G memory split.
was also supported by UML 2.4. I think unusual split and the UML trivial support for that were born and used when 4G/4G didn't exist yet (or maybe not even highmem?).
Quoted 3 lines
2.4 support aside, my aim is to have a single uml binary that will work on arbitrary host kernels. How difficult will it be to implement support for dynamic offsets for these pages in skas0?
I don't think it's easy - however, it can be done. Below my idea - Jeff, please comment on this
In assembly.
It goes like this:
call label /*this is coded like a relative jump, i.e. call +1*/
label: pop $eax /*we got the saved EIP*/
/* Now we can round EIP and subtract an offset to calculate the data page location.
*/
The only problem is that it must be done in assembly and at times this must be redone (we don't have enough registers to save the value across a 6-param syscall), and touching this code is a bit dangerous.
Quoted 1 line
Jason
Signature · 23 lines
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 6 lines · Blaisorblade
I don't think it's easy - however, it can be done. Below my idea - Jeff, please comment on this
In assembly.
It goes like this:
Quoted 6 lines
call label /*this is coded like a relative jump, i.e. call +1*/
label: pop $eax /*we got the saved EIP*//* Now we can round EIP and subtract an offset to calculate the data page location.
*/
How does this give us the location of the data page?
You really want to know the end of the process address space, which you can do by taking the address of a convenient local and rounding up to the nearest 1G or .5G or so.
Jeff
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 7 lines · Jeff Dike
Quoted 5 lines · Blaisorblade
I don't think it's easy - however, it can be done. Below my idea - Jeff, please comment on this
In assembly.
It goes like this:
Quoted 8 lines
Quoted 6 lines
call label /*this is coded like a relative jump, i.e. call +1*/
label: pop $eax /*we got the saved EIP*//* Now we can round EIP and subtract an offset to calculate the data page location.
*/How does this give us the location of the data page?
The EIP is inside the stub code page, and the two pages are one near the other.
Quoted 3 lines
You really want to know the end of the process address space, which you can do by taking the address of a convenient local and rounding up to the nearest 1G or .5G or so.
You can't do that in the stub; however, what you suggest or something similar is probably needed outside the stub, from the kernel code, when you need to map it somewhere inside the process memory.
However, currently, the rounding can't be 0.5G, it must be 0.25G with the current code, and it's still fragile if the host code is changed.
(arch/i386/Kconfig)
config PAGE_OFFSET
hex
default 0xB0000000 if VMSPLIT_3G_OPT
default 0x78000000 if VMSPLIT_2G
default 0x40000000 if VMSPLIT_1G
default 0xC0000000Signature · 23 lines
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 10 lines · [email protected] said:
However, currently, the rounding can't be 0.5G, it must be 0.25G with the current code, and it's still fragile if the host code is changed.
(
arch/i386/Kconfig)
configPAGE_OFFSEThex default 0xB0000000 if VMSPLIT_3G_OPT default 0x78000000 if VMSPLIT_2G default 0x40000000 if VMSPLIT_1G default 0xC0000000
Yes, I don't think other choices are too unlikely in the future. 0xB0000000 was only chosen because it prevents a typical 32-bit machine with 1G of ram from having 1/8 of it in a little 128M highmem zone. In the future, "typical" could likely be something else.
Jason
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 2 lines · Blaisorblade
The EIP is inside the stub code page, and the two pages are one near the other.
I think you're going to have to talk more slowly and use shorter words.
The problem is that we need to figure out at runtime where to put the stub pages, correct? And we can't use the code stub page to figure out where it is, because we haven't mapped it yet, because we don't know where to put it, correct?
Quoted 10 lines
However, currently, the rounding can't be 0.5G, it must be 0.25G with the current code, and it's still fragile if the host code is changed.
(
arch/i386/Kconfig)
configPAGE_OFFSEThex default 0xB0000000 if VMSPLIT_3G_OPT default 0x78000000 if VMSPLIT_2G default 0x40000000 if VMSPLIT_1G default 0xC0000000
How much can stack randomization vary? If it can vary more than the split varies, which I would expect, then rounding the stack pointer isn't going to work.
Another approach is to start with the current top of stack and try mapping pages at increments equal to the smallest split granularity that we think we are going to see, until one fails.
Jeff
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 5 lines · Jeff Dike
Quoted 2 lines · Blaisorblade
The EIP is inside the stub code page, and the two pages are one near the other.
I think you're going to have to talk more slowly and use shorter words.
Yes, I've been a bit too fast :-)
Quoted 4 lines
The problem is that we need to figure out at runtime where to put the stub pages, correct? And we can't use the code stub page to figure out where it is, because we haven't mapped it yet, because we don't know where to put it, correct?
That is problem #1, and exists; but when answering I thought to problem #2, i.e. that the stub code currently hardcodes the location of the stub data page, and that this must be fixed; I didn't notice that we must first put the stubs somewhere.
So I remembered that trick to get EIP which I read time ago (the purpose was to make some code Position-Independent exactly injecting some code into another process address space).
Btw, PIC library are another story because they're told their location (IIRC, I forget the details).
Actually, we need to figure were to place the pages, so we could _maybe_ as well pass the address to the stub in a register. I'm quite unsure of this however as at least clone.c for i386 uses _all_ available registers for the 6-param syscall call.
Quoted 3 lines
How much can stack randomization vary? If it can vary more than the split varies, which I would expect, then rounding the stack pointer isn't going to work.
Dunno, but even if it currently works, we'd better find a solution without the assumption that stack randomization doesn't create problem.
Quoted 1 line
Another approach is to start with the current top of stack
How do you get that?
Quoted 3 lines
and try
mapping pages at increments equal to the smallest split granularity that we think we are going to see, until one fails.
I don't like the idea of parsing /proc/XXX/maps, but I must mention it too; however, the format changed slightly in the various kernels, so it's particularly a bad idea.
bfff9000-c0000000 rwxp bfff9000 00:00 0 [stack]
Signature · 23 lines
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 4 lines · Blaisorblade
That is problem #1, and exists; but when answering I thought to problem #2, i.e. that the stub code currently hardcodes the location of the stub data page, and that this must be fixed; I didn't notice that we must first put the stubs somewhere.
I see - you're one problem ahead of me.
I'm wondering if we can play some linker tricks for this. Stick a word of data on the code page and put the data page address in it. Then the stub just reads that in order to get the data.
Quoted 4 lines
So I remembered that trick to get EIP which I read time ago (the purpose was to make some code Position-Independent exactly injecting some code into another process address space).
That's the standard way of getting your EIP on x86 since there's no move from EIP instruction. That will work, too, but (as you point out) requires a register.
Quoted 1 line
Quoted 1 line
Another approach is to start with the current top of stack
Hmmmm :-) Maybe easier said than done. I was thinking about figuring that out as basically the first thing in main, but I can think of reasons that wouldn't be robust.
Other schemes, which involve a binary search for the boundary by using test mmaps, involve the risk of unmapping part of the stack.
Jeff
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 11 lines · Jeff Dike
Quoted 4 lines · Blaisorblade
That is problem #1, and exists; but when answering I thought to problem #2, i.e. that the stub code currently hardcodes the location of the stub data page, and that this must be fixed; I didn't notice that we must first put the stubs somewhere.
I see - you're one problem ahead of me.
I'm wondering if we can play some linker tricks for this. Stick a word of data on the code page and put the data page address in it. Then the stub just reads that in order to get the data.
After you place the stubs somewhere, you can pass them the address in a register. Indeed, we already do that since the stack in located inside the data page, so you simply need to round that (hardcoding at compile-time the data size page, but we already do that).
Passing that in a memory word doesn't work unless you use Instruction Pointer relative addressing, only available (to my knowledge) in x86_64 as RIP-relative addressing.
Quoted 2 lines
That will work, too, but (as you point
out) requires a register.
Not a big problem - you can recalculate it at will so that's not a real problem as long as we can recalculate if without problems (which could probably require switching to full assembler).
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Another approach is to start with the current top of stack
Hmmmm :-) Maybe easier said than done. I was thinking about figuring that out as basically the first thing in main, but I can think of reasons that wouldn't be robust.
Can we remove the assumption the pages are at the absolute top of the address space?
The guest process doesn't risk unmapping them because we stop it from that, with gate_vma's for instance, even if I know that's a work in progress from Bodo's comments (not yet begun).
We could block mmapping over the used address, and we must do that anyway - SKAS3 indeed would fail on 2G/2G and such hosts exactly because we don't do that and our mmap() returns addresses beyond host TASK_SIZE.
However, this doesn't happen because we already implement the "top of the stack" detection technique in arch/um/kernel/skas/mem.c. So we've well-tested code doing this, even if maybe at times suboptimal.
But how much does stack randomization changes? That's the only remaining doubt.
Signature · 23 lines
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 3 lines · Blaisorblade
However, this doesn't happen because we already implement the "top of the stack" detection technique in
arch/um/kernel/skas/mem.c. So we've well-tested code doing this, even if maybe at times suboptimal.
About that code,
$ find arch/um/ include/asm-um |xargs grep HOST_TASK_SIZE
finds no mention of CONFIG_HOST_TASK_SIZE anywhere else, so that should be removed it seems (unless it's for S390, but that port is stalling - there's no point in still waiting to merge it, we must either merge or drop it depending on the fact that we have at least 1 active user).
Signature · 20 lines
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive http://it.messenger.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel