line-devel — LINE development list

RE: [line-devel] int 80 and line operation

[Michael V. <mi...@bl...>]

On Wed, 18 Apr 2001, Michael Stout wrote:

>
> No. I dont really have a place to put it.
> I can send it to you or ftp it or whatever
> 	Mike

If you want, email it to me and I'll put it up on the LINE homepage.

Mike

RE: [line-devel] int 80 and line operation

[Michael S. <ms...@ac...>]

No. I dont really have a place to put it.
I can send it to you or ftp it or whatever
	Mike

-----Original Message-----
From: Michael Vines [mailto:mi...@bl...]
Sent: Wednesday, April 18, 2001 12:39 PM
To: Michael Stout
Cc: lin...@li...
Subject: Re: [line-devel] int 80 and line operation


On Wed, 18 Apr 2001, Michael Stout wrote:

>
> I've been able to hook int 80 in a kernel mode device driver and send the
> eax register and the process ID via a local procedure call to a user mode
> application. which can be debugged using vc++. sending the other registers
> shouldnt be a problem.
>
> Theres also some code that creates a process and emptys it out so that It
is
> free to have raw linux executables mapped into it.
>
> this is developed with vc++ and the NT ddk. It runs under 4.0 and 2000
>  I really dont have much time to mess around with this anymore and
> would be happy have help with it.
>
> My thoughts on how to advance the project
> 1) Modify the kernel level driver to pass all the registers to the port
> 	a) the ring0 prolog for the interrupt handler trashes a register.
> 	b) slight modifications to passing the data through the port.
> 2) figure out why the kernel mode driver fails to initialize the first
time
> it is loaded.
> 3) Merge the port server with the user-mode application that calls the
> kernel mode driver to set up the interrupt handler
> 4) Merge the code to create an empty process into the user-mode
application
> 5) poke into that process an int 80 that calls execve
> 6) go nuts implementing apis in the user mode code.
> 7) move code into the kernel mode device driver so system calls dont have
to
> jump into and out of kernel mode all the time.

That sounds really interesting.  Is the code available online somewhere?


Mike

Re: [line-devel] int 80 and line operation

[Michael V. <mi...@bl...>]

On Wed, 18 Apr 2001, Michael Stout wrote:

>
> I've been able to hook int 80 in a kernel mode device driver and send the
> eax register and the process ID via a local procedure call to a user mode
> application. which can be debugged using vc++. sending the other registers
> shouldnt be a problem.
>
> Theres also some code that creates a process and emptys it out so that It is
> free to have raw linux executables mapped into it.
>
> this is developed with vc++ and the NT ddk. It runs under 4.0 and 2000
>  I really dont have much time to mess around with this anymore and
> would be happy have help with it.
>
> My thoughts on how to advance the project
> 1) Modify the kernel level driver to pass all the registers to the port
> 	a) the ring0 prolog for the interrupt handler trashes a register.
> 	b) slight modifications to passing the data through the port.
> 2) figure out why the kernel mode driver fails to initialize the first time
> it is loaded.
> 3) Merge the port server with the user-mode application that calls the
> kernel mode driver to set up the interrupt handler
> 4) Merge the code to create an empty process into the user-mode application
> 5) poke into that process an int 80 that calls execve
> 6) go nuts implementing apis in the user mode code.
> 7) move code into the kernel mode device driver so system calls dont have to
> jump into and out of kernel mode all the time.

That sounds really interesting.  Is the code available online somewhere?


Mike

[line-devel] int 80 and line operation

[Michael S. <ms...@ac...>]

I've been able to hook int 80 in a kernel mode device driver and send the
eax register and the process ID via a local procedure call to a user mode
application. which can be debugged using vc++. sending the other registers
shouldnt be a problem.

Theres also some code that creates a process and emptys it out so that It is
free to have raw linux executables mapped into it.

this is developed with vc++ and the NT ddk. It runs under 4.0 and 2000
 I really dont have much time to mess around with this anymore and
would be happy have help with it.

My thoughts on how to advance the project
1) Modify the kernel level driver to pass all the registers to the port
	a) the ring0 prolog for the interrupt handler trashes a register.
	b) slight modifications to passing the data through the port.
2) figure out why the kernel mode driver fails to initialize the first time
it is loaded.
3) Merge the port server with the user-mode application that calls the
kernel mode driver to set up the interrupt handler
4) Merge the code to create an empty process into the user-mode application
5) poke into that process an int 80 that calls execve
6) go nuts implementing apis in the user mode code.
7) move code into the kernel mode device driver so system calls dont have to
jump into and out of kernel mode all the time.

Re: [line-devel] Re: UML under LINE

[Erik P. <epa...@cs...>]

On Wed, Apr 18, 2001 at 10:21:27AM -0400, Michael Vines wrote:
> 
> > I picked up a book this weekend on the native Windows API - there's a
> > function called "ZwMapViewOfSection". The docs say:
> > "When mapping pagefile and datasections, BasedAddress and SSection Offset must
> > be aligned with the system's allocation granularity unless the AllocationType
> > flags include AT_ROUND_TO_PAGE; in which case, they are rounded down to the
> > next page boundary."
> >
> > As soon as I finish my CS757 midproject-report I was going to play around
> > with writing a bit of code to see if this really works or not....
> 
> Very cool, that would be perfect. The Zw* functions are only available
> in NT/2000 right?

I don't know. I think so.

> What's the book called?
> 

"Windows NT/2000 Native API Reference", Gary Nebbett, MTP 2000
ISBN 1-57870-199-6

-Erik

> 
> Mike
> 
> 
> 
> _______________________________________________
> line-devel mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/line-devel

Re: [line-devel] Re: UML under LINE

[Michael V. <mi...@bl...>]

On Wed, 18 Apr 2001, Erik Paulson wrote:

> I picked up a book this weekend on the native Windows API - there's a
> function called "ZwMapViewOfSection". The docs say:
> "When mapping pagefile and datasections, BasedAddress and SSection Offset must
> be aligned with the system's allocation granularity unless the AllocationType
> flags include AT_ROUND_TO_PAGE; in which case, they are rounded down to the
> next page boundary."
>
> As soon as I finish my CS757 midproject-report I was going to play around
> with writing a bit of code to see if this really works or not....

Very cool, that would be perfect. The Zw* functions are only available
in NT/2000 right?   What's the book called?


Mike

Re: [line-devel] Re: UML under LINE

[Erik P. <epa...@cs...>]

On Wed, Apr 18, 2001 at 10:07:21AM -0400, Michael Vines wrote:
> On Wed, 18 Apr 2001, Boaz Harrosh wrote:
> 
> >     You wrote on http://Line.sourceforge.net/faq.php ...
> >
> > >    I say "meaningful" because I think that if the UML page size were to be
> > >bumped up to 64K, a UML port to Win32 would be possible. However that would
> > >likely mean that native x86 Linux binaries could not be loaded/run on
> > >UML-Win32. You would have to recompile everything for the UML-Win32
> > >platform.
> >
> >     Well I think I see a solution here that will solve the problem..
> >
> <snip snip>
> >
> >     If you can point me to the right place in the UML code I will write it
> > myself. I will go head and write a test Lib that will make a MapViewOfFileEx
> > functionality that can accept 4K pages.
> 

I picked up a book this weekend on the native Windows API - there's a 
function called "ZwMapViewOfSection". The docs say:
"When mapping pagefile and datasections, BasedAddress and SSection Offset must
be aligned with the system's allocation granularity unless the AllocationType
flags include AT_ROUND_TO_PAGE; in which case, they are rounded down to the
next page boundary."

As soon as I finish my CS757 midproject-report I was going to play around 
with writing a bit of code to see if this really works or not....

-Erik

> I need to update that question on the FAQ.  There is a thread with the
> subject "Win32 port of UML unlikely" on the uml-devel mailing list where
> Jeff Dike (UML maintainer) and I discuss something similair.  Jeff
> provided some pointers on where to start as well.
> 
> 
> > P.S do you have some mailing list for LINE. I think I will post this on the
> > UML mailing list too.
> 
> lin...@li...
> 
> 
> 
> Mike
> 
> 
> 
> _______________________________________________
> line-devel mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/line-devel

[line-devel] Re: UML under LINE

[Michael V. <mi...@bl...>]

On Wed, 18 Apr 2001, Boaz Harrosh wrote:

>     You wrote on http://Line.sourceforge.net/faq.php ...
>
> >    I say "meaningful" because I think that if the UML page size were to be
> >bumped up to 64K, a UML port to Win32 would be possible. However that would
> >likely mean that native x86 Linux binaries could not be loaded/run on
> >UML-Win32. You would have to recompile everything for the UML-Win32
> >platform.
>
>     Well I think I see a solution here that will solve the problem..
>
<snip snip>
>
>     If you can point me to the right place in the UML code I will write it
> myself. I will go head and write a test Lib that will make a MapViewOfFileEx
> functionality that can accept 4K pages.

I need to update that question on the FAQ.  There is a thread with the
subject "Win32 port of UML unlikely" on the uml-devel mailing list where
Jeff Dike (UML maintainer) and I discuss something similair.  Jeff
provided some pointers on where to start as well.


> P.S do you have some mailing list for LINE. I think I will post this on the
> UML mailing list too.

lin...@li...



Mike

Re: [line-devel] Oops

[Michael V. <mi...@bl...>]

On Tue, 17 Apr 2001, Nelson Rush wrote:

> I apologize, I just read the docs/overview readme which states:
>
> "Finally instead of reimplementing all the Linux syscalls itself, LINE
> simply
> uses the Cygwin API which already provides a POSIX-like enviroment. Most of
> the syscalls are just redirected to their Cygwin equivalents."
>
> Which of course explains why my attempts at getting LINE to compile in MSVC
> are futile.

Yes, LINE pretty much requires Cygwin.  Not so much for the gcc compiler,
although it does use some gcc C extensions (as you discovered with the log
macros), but more for the Cygwin runtime environment.

Also since Cygwin is GPLed, you can be sure that everybody will be
able to build it themselves.  Although I will admit that the MSVC debugger
is much nicer :)

Mike

[line-devel] Oops

[Nelson R. <pal...@us...>]

I apologize, I just read the docs/overview readme which states:

"Finally instead of reimplementing all the Linux syscalls itself, LINE
simply
uses the Cygwin API which already provides a POSIX-like enviroment. Most of
the syscalls are just redirected to their Cygwin equivalents."

Which of course explains why my attempts at getting LINE to compile in MSVC
are futile.

Next time I should just read the documentation first.

Sincerely,
Nelson Rush

"I will never let my schooling get in the way of my education." --Mark Twain

[line-devel] LINE VC6 port, no cygwin needed, batteries not included

[Nelson R. <pal...@us...>]

I've modified Line v0.4 to compile in Visual C 6.x without cygwin. It
compiles, it runs, it has some problems.

Problems:

1) I didn't know what to do with your log macros, so I commented them out.
MSVC didn't like them.

2) I had to link getopt.c, getopt1.c and include getopt.h along with LINE
with a few modifications in order to use getopt w/out cygwin. In fact, if
you read getopt.c in the Line/src/posix directory you'll see that the glibc
authors intended it to be linked to code seperate from the library if a
compiler didn't support it yet.

3) I wrote a wrapper for getpid to work in Win32.

4) I had to bypass the cygwin path conversion functions (I don't know what
they do yet.) by doing a: linedir = strdup(".");   for the -l=blah option.
It defaults to the current directory if you use the -l option with any
parameter. I'm not looking forward to making a replacement function. I don't
have cygwin, but maybe someone could just extract this function out of
cygwin and slip it in somewhere.

5) It runs fine but if you try to load a Linux ELF executable file you will
see some errors relating to getrlimit and cygwin. I haven't tracked this
down yet, but when I get more time I will.

6) The resulting executable is 130k compared to the 80k cygwin executable,
this cannot be a good thing.

The MSVC project files are included in the package, along with the getopt
files and the modified LINE source. I haven't played with linexec or linelog
yet so you'll have to use the originals in the same directory.

The only source file that has changed is Line.c and log.h

I've gone through and commented out every call to the log macros, please
forgive me. I was much more interested in getting the thing to compile. ;-)

A quick note on the getopt stuff:

posix/getopt.c

.. contains the code for getopt

posix/getopt1.c

.. contains a wrapper for getopt_long

These were the filenames given by the glibc authors, it may be wise to keep
them named in this way. They have been slightly modified so they would
compile normally in Win32.

This new version can be downloaded here:
http://palisade.rm-f.net/line-0.41.zip

Hope this is helpful.

Sincerely,
Nelson Rush

"I will never let my schooling get in the way of my education." --Mark Twain

Re: [line-devel] Problem related to X

[Michael V. <mi...@bl...>]

On Fri, 6 Apr 2001, Vivek Jishtu wrote:

> I have a Win98 machine and LINE-0.4 seems to work quite well. Bash seems to
> crash so I am using bsh, most of the text based applications seem to work. I
> tried to run the XPaint application but I get the error "Can't open
> display". The reason could be because it cannot find the X server. I have
> copied all the library files Xpaint requires to the /lib directory. What
> other files are required to run XPaint, or more importantly how do I start
> the X-Server.

Hi,

LINE doesn't have an X-Server built in, and LINE can't run a Linux
X-Server yet (and probably never).  You'll need to either find a Windows
X-Server or maybe use a Linux X-Server on your network somewhere.

Note that unless you've copied over all the libnss*.so shared objects from
Linux, you won't have DNS so you'll have to specify the X-Server by IP
address.  I'd recommmend using just IP addresses anyways, at least until
you are sure it's working.


Mike

[line-devel] Problem related to X

[Vivek J. <viv...@ya...>]

I have a Win98 machine and LINE-0.4 seems to work quite well. Bash seems to
crash so I am using bsh, most of the text based applications seem to work. I
tried to run the XPaint application but I get the error "Can't open
display". The reason could be because it cannot find the X server. I have
copied all the library files Xpaint requires to the /lib directory. What
other files are required to run XPaint, or more importantly how do I start
the X-Server.

Thanks in advance,

Vivek Jishtu


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [line-devel] mmap on LINE

[Michael V. <mi...@bl...>]

On Sun, 1 Apr 2001, Erik Paulson wrote:

> > On Sat, 10 Mar 2001, Erik Paulson wrote:
> >
> > > Well, if nothing else this post will serve to see if the message archives
> > > work :)
> >
>
> It doesn't actually appear that the archives work yet...

I think it's ok now.  I didn't have archiving enabled on the mailing list,
seems you need to explicitly enable it.


> But anyway, this is related to your post on the UML list the other day -
> how do you implement mmap() under LINE if Win32 requires you to use
> 64K chunks?

With lots of ugly kludges :)

(here's link to that post if anybody wants a little bit of background
 http://www.geocrawler.com/archives/3/709/2001/3/0/5450072/ )


When MAP_SHARED is used, LINE has no choice but to forward the request to
the Cygwin mmap().  I guess it could handle it internally, but LINE would
be doing the exact same thing as Cygwin is doing so there is no point.
Cygwin uses MapViewOfFileEx() to perform the actual maping.  This is the
only Win32 API function that will allow processes to share memory.

So LINE also suffers from the 64K alignment issue, but LINE tries hard to
hide the problem. It really only comes into play when you do a
mmap(MAP_SHARED | MAP_FIXED).  Most apps seem to just use MAP_SHARED and
don't really care where the memory gets placed.  UML being one of the
exceptions to this.

The Win32 API does not explictly state 64K alignment, the actual
number is implementation dependent.  However all current Win32
implementations use 64K, but maybe WinXP will be better.


MAP_PRIVATE is a completely different beast.  It is handled completely
internally by LINE.  The Cygwin mmap() can't be used because Cygwin still
uses MapViewOfFileEx() for private mappings.  This is problematic because
the ELF loader often does mmap(MAP_PRIVATE|MAP_FIXED) at page alignment.
This would make it impossible to even load a simple hello world app, so
LINE does it's own memory allocation with VirtualAlloc() and friends.


But there is a trade-off, the major problem with using VirtualAlloc() is
that if you are mapping part of a file into memory. LINE must read the
file into memory immediately.


There are actually a number of incompatibilities between the LINE mmap()
and Linux mmap().  Another notable problem is that Linux lets you mmap()
the same region of memory multiple times, possibly changing the mapping
type at the same time (MAP_SHARED => MAP_PRIVATE or something).  LINE
won't let you do that.


Mike

[line-devel] mmap on LINE

[Erik P. <epa...@cs...>]

> On Sat, 10 Mar 2001, Erik Paulson wrote:
> 
> > Well, if nothing else this post will serve to see if the message archives
> > work :)
> 

It doesn't actually appear that the archives work yet...

But anyway, this is related to your post on the UML list the other day - 
how do you implement mmap() under LINE if Win32 requires you to use 
64K chunks?

-Erik