[uml-devel] Re: (implementation idea) Re: uml and nonstandard memory splits?

[uml-devel] Re: (implementation idea) Re: uml and nonstandard memory splits?

[Jeff Dike]

On Fri, Mar 24, 2006 at 01:56:32AM +0100, Blaisorblade wrote:
> 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.
> */

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: (implementation idea) Re: uml and nonstandard memory splits?

[Blaisorblade]

On Friday 24 March 2006 03:30, Jeff Dike wrote:
> On Fri, Mar 24, 2006 at 01:56:32AM +0100, Blaisorblade wrote:
> > 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.
> > */

> 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.

> 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 0xC0000000

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: (implementation idea) Re: uml and nonstandard memory splits?

[Jason Lunz]

blaisorblade@yahoo.it 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)
> config PAGE_OFFSET
>         hex
>         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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: (implementation idea) Re: uml and nonstandard memory splits?

[Jeff Dike]

On Fri, Mar 24, 2006 at 03:34:01PM +0100, Blaisorblade wrote:
> 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?

> 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 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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: (implementation idea) Re: uml and nonstandard memory splits?

[Blaisorblade]

On Friday 24 March 2006 18:26, Jeff Dike wrote:
> On Fri, Mar 24, 2006 at 03:34:01PM +0100, Blaisorblade wrote:
> > 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 :-)

> 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.

> 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.

> Another approach is to start with the current top of stack

How do you get that?

> 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]

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: (implementation idea) Re: uml and nonstandard memory splits?

[Jeff Dike]

On Mon, Mar 27, 2006 at 11:30:05PM +0100, Blaisorblade wrote:
> 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.

> 
> 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.

> > 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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: (implementation idea) Re: uml and nonstandard memory splits?

[Jeff Dike]

On Mon, Mar 27, 2006 at 11:33:37PM +0100, Blaisorblade wrote:
> Especially maybe_map must pin the pages (see implementation of 4G/4G 
> copy_*_user from Ingo Molnar).

Yup, looks like we can follow Ingo's implementation on this one.

> I'll work on this, I had come up with a nice design time ago, if you merge a 
> lockless filehandle I'll be glad to add locking to it. If you have a somehow 
> stable code base on it, let me know and I'll work on the patches.

I believe that the filehandle that's in my patchset is stable.  I've
beat on it with hostfs with no problems.  humfs is less healthy, but
it looks like the problems don't have anything to do with filehandle.

> My design was that you:
> a) take the list lock
> b) remove the fd from the list
> c) drop the list lock
> instead of simply bringing the fd upfront
> d) call read (or whatever) on the interested fd
> e) redo a)-c) but now to _add_ the fd on list, on the front

Which was pretty much the get_fh() and put_fh() I was considering.
It's just a pain to have to wrap that around every file access.

> This may also need a reference count if in step b) the fd may already be on 
> the list.

The scenario I think you have in mind is
	one process gets an fd for file I/O
	so does another one
	the first process finishes and sticks the thing back on the
list
	it is reclaimed, screwing the second process, which hasn't
made the system call yet

In this case, get_fh should just increment a count, put_fh should
decrement it, and the only list operation should be to move it to the
end of the list so it's last to be reclaimed.  The reclaimer would not
reclaim filehandles with non-zero counts.  I see no point in removing
it from the list and adding it back, as that seems not to protect
against anything.

> *) when _any_ fd API of the existing set (os_*) is called, it detects 
> -EMFILE/-ENFILE and closes fd's on the back of the list (i.e. we do LRU on 
> the list)

You're envisioning the os_* interfaces calling back into filehandle.c
to get a descriptor if needed?  That would make this whole thing less
"layery", which I can see.

> *) using new APIs is only needed to register an fd as "reclaimable" - this is
> optional since it can be used only for file-based fds (not for pipes, 
> probably not for sockets)

Which is how things work now, as is_reclaimable is called only when it
is known that a file has been opened.

				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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel