Re: copy to suer space

Re: copy to suer space

[Luís Henriques]

On Tuesday 20 November 2001 07:31 pm, Tyler BIRD wrote:
> What is the other "specifc event that occurs" you could write a spinlock
> and the other thread that causes the event could release that lock
> Of course interrups should be enabled when some thing like this should
> happen Is this other event a interrupt?

The specific event is a breakpoint interrupt: when a specific memory address 
is used (for opcode fetch/read/write) in the addressing space of a process, 
then an exception is raised and a handler for this exception will be called - 
this is my module.

>
>
> There are various ways I'll have to look up when I get home.
> you could alter the cs if you change the vma properties especially the
> permissions properties and you can do this I just don't have the details
> now.
>
> the cs is protected by default
> Tyler
>

-- 
Luís Henriques

Re: copy to suer space

[Joerg Pommnitz]

Nick LeRoy <nleroy@cs.wisc.edu> wrote:

 > Linux executables are "demand paged".  What this means is that they are

 > loaded as they are "page faulted" in.  If low on memory, the kernel 
 > may, at it's discression, discard text pages at any time.  When a 
 > discarded page is referenced, a page fault occurs, and the page is re-
 > loaded from the executable.  They are *never* written out to swap 
 > space.  The kernel fully expects the text file and the text memory 
 > pages to not be modified during execution.

Clean pages are never written to swap space. If the page is dirty, it's
just another data page. If it were otherwise, non-PIC shared libraries
that require fixups from the dynamic linker would not work.

Regards
  Joerg


=====
-- 
Regards
       Joerg


__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

Re: copy to suer space

[Anton Altaparmakov]

At 16:40 20/11/01, Luis Miguel Correia Henriques wrote:
>I'm trying to implement a kernel module that will be changing a user
>process' code segment. I tried to user copy_to_user to patch the process's
>code but, when I tried to read the new code (just to check...), it didn't
>worked. Why was that? And what is the solution?

I don't think what you are trying to do is possible. Even if you somehow 
managed to write over the code segment of a user space process (which I 
very much doubt would be possible as I assume the memory is mapped 
read-only), as soon as the kernel pages out (i.e. discards!) some portion 
of the executable due to memory shortage your changes would be lost, since 
the paging back into memory would happen by reading the executable back 
from disk, which would mean it would read the unmodified code into memory...

Why would you want to do such a thing anyway? Kernel modifying userspace 
binaries in memory sounds like a really flawed idea which is just begging 
for problems. - Just recompiling the user space program with the smallest 
change would make the new binary code incompatible with your predefined 
module...

But perhaps I misunderstood you?

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: copy to suer space

[Luís Henriques]

> I don't think what you are trying to do is possible. Even if you somehow
> managed to write over the code segment of a user space process (which I
> very much doubt would be possible as I assume the memory is mapped
> read-only)

Is there a way to solve this problem? To temporarly turn it read/write?

>, as soon as the kernel pages out (i.e. discards!) some portion
> of the executable due to memory shortage your changes would be lost, since
> the paging back into memory would happen by reading the executable back
> from disk, which would mean it would read the unmodified code into
> memory...

When I'm modifing the code, I'm sure that the page is in memory because my 
code is called from the user space, in the exact location where I want to 
change it (with a breakpoint interruption...)

The point is that I can't write to the memory location I want... How do I 
solve this?

-- 
Luís Henriques

Re: copy to suer space

[Andreas Dilger]

On Nov 20, 2001  17:08 +0000, Luís Henriques wrote:
> > I don't think what you are trying to do is possible. Even if you somehow
> > managed to write over the code segment of a user space process (which I
> > very much doubt would be possible as I assume the memory is mapped
> > read-only)
> 
> Is there a way to solve this problem? To temporarly turn it read/write?
> 
> >, as soon as the kernel pages out (i.e. discards!) some portion
> > of the executable due to memory shortage your changes would be lost, since
> > the paging back into memory would happen by reading the executable back
> > from disk, which would mean it would read the unmodified code into
> > memory...
> 
> When I'm modifing the code, I'm sure that the page is in memory because my 
> code is called from the user space, in the exact location where I want to 
> change it (with a breakpoint interruption...)
> 
> The point is that I can't write to the memory location I want... How do I 
> solve this?

Maybe if you describe the actual problem that you are trying to solve, and
not the actual way you are trying to solve it, there may be a better method.
Usually, if something you are trying to do is very hard to do, there is a
different (much better) way of doing it.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: copy to suer space

[Luís Henriques]

> Maybe if you describe the actual problem that you are trying to solve, and
> not the actual way you are trying to solve it, there may be a better
> method. Usually, if something you are trying to do is very hard to do,
> there is a different (much better) way of doing it.
>
> Cheers, Andreas

OK, here it goes:

I'm developping a kernel module that needs to delay a process, that is, he 
receives a PID and, when a specific event occurs, that process shall be 
delayed. This delay shall be done in a way that the process keeps burning CPU 
time (it can not be, e.g., put in a waiting-list...).
The solution I found was to change its code segment, putting a loop in it. 
After a specified period of time, the original code must be restored and the 
process must keep going as nothing happened.
The main problem I found was already explained: can't write to the CS!

-- 
Luís Henriques

Re: copy to suer space

[Hua Zhong]

Why not SIGSTOP/SIGCONT instead?

I don't see any reason why you should change the code segment (reminded me
some ugly Windows hacks of changing DLL entries).

----- Original Message -----
From: "Luís Henriques" <lhenriques@criticalsoftware.com>
To: "Andreas Dilger" <adilger@turbolabs.com>
Cc: "Anton Altaparmakov" <aia21@cam.ac.uk>; <linux-kernel@vger.kernel.org>
Sent: Tuesday, November 20, 2001 10:44 AM
Subject: Re: copy to suer space


>
> > Maybe if you describe the actual problem that you are trying to solve,
and
> > not the actual way you are trying to solve it, there may be a better
> > method. Usually, if something you are trying to do is very hard to do,
> > there is a different (much better) way of doing it.
> >
> > Cheers, Andreas
>
> OK, here it goes:
>
> I'm developping a kernel module that needs to delay a process, that is, he
> receives a PID and, when a specific event occurs, that process shall be
> delayed. This delay shall be done in a way that the process keeps burning
CPU
> time (it can not be, e.g., put in a waiting-list...).
> The solution I found was to change its code segment, putting a loop in it.
> After a specified period of time, the original code must be restored and
the
> process must keep going as nothing happened.
> The main problem I found was already explained: can't write to the CS!
>
> --
> Luís Henriques
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: copy to suer space

[Andreas Dilger]

On Nov 20, 2001  18:44 +0000, Luís Henriques wrote:
> > Maybe if you describe the actual problem that you are trying to solve, and
> > not the actual way you are trying to solve it, there may be a better
> > method. Usually, if something you are trying to do is very hard to do,
> > there is a different (much better) way of doing it.
> 
> I'm developping a kernel module that needs to delay a process, that is, he 
> receives a PID and, when a specific event occurs, that process shall be 
> delayed. This delay shall be done in a way that the process keeps burning CPU 
> time (it can not be, e.g., put in a waiting-list...).

Putting it into a waiting-list is by far the best solution.  This is a normal
Unix operation, like SIGSTOP, SIGCONT, and could even be done from user space.

What is the requirement that it keeps burning CPU for?  Generally, this is
what you do NOT want to do.

Depending on what that is for, you could just increment the "system time"
ticks in the process, which is kind of a hack, but not nearly so ugly as
changing the user-space code (which is truly dreadful, and I don't think
anyone on this list would ever help you do that, even if they could).

The other alternative is to make your module such that upon entry, the
user process simply busy-waits until the delay is complete.  This is also
easy to do, with something like udelay().

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: copy to suer space

[Mike Fedyk]

On Tue, Nov 20, 2001 at 12:39:15PM -0700, Andreas Dilger wrote:
> On Nov 20, 2001  18:44 +0000, Lu?s Henriques wrote:
> > > Maybe if you describe the actual problem that you are trying to solve, and
> > > not the actual way you are trying to solve it, there may be a better
> > > method. Usually, if something you are trying to do is very hard to do,
> > > there is a different (much better) way of doing it.
> > 
> > I'm developping a kernel module that needs to delay a process, that is, he 
> > receives a PID and, when a specific event occurs, that process shall be 
> > delayed. This delay shall be done in a way that the process keeps burning CPU 
> > time (it can not be, e.g., put in a waiting-list...).
> 
> Putting it into a waiting-list is by far the best solution.  This is a normal
> Unix operation, like SIGSTOP, SIGCONT, and could even be done from user space.
> 
> What is the requirement that it keeps burning CPU for?  Generally, this is
> what you do NOT want to do.
> 

This to me looks like the main desire is to fool the user.  It looks like it
doing something, but it really isn't...

Re: copy to suer space

[Luís Henriques]

> This to me looks like the main desire is to fool the user.  It looks like
> it doing something, but it really isn't...

Not really... This may look like an old DOS virus :) but it is not! It's a 
fault injection tool - it's purpose (in this case, of corse) is to cause a 
very short delay on a critic process.

-- 
Luís Henriques

Re: copy to suer space

[Juan Quintela]

>>>>> "luís" == Luís Henriques <umiguel@alunos.deis.isec.pt> writes:

>> This to me looks like the main desire is to fool the user.  It looks like
>> it doing something, but it really isn't...

luís> Not really... This may look like an old DOS virus :) but it is not! It's a 
luís> fault injection tool - it's purpose (in this case, of corse) is to cause a 
luís> very short delay on a critic process.

What is wrong putting a signal handler in your process for a signal,
and busy wait in that signal all the time that you want?

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: copy to suer space

[Luís Henriques]

> What is wrong putting a signal handler in your process for a signal,
> and busy wait in that signal all the time that you want?

The point is that I'm implementing a tool that shall test fault tolerance (in 
the user processes, operating system, architecture, ...). The process is not 
supposed to know that he is being delayed!

n0ano suggested me another solution (thanks n0ano!!!): instead of altering 
the CS, I just put some code to the process stack, return to the SS:ESP 
(instead of CS:EIP) and, later, restore the stack and return to the process.

This is not working yet because it's - I'm having some problems with it. 
Could anyone look at this code and tell me where it can fail?

	rdtsc
	movl %eax, %ecx
	addl $0x1, %ecx
   loop:
	rdtsc
	cmp %ecx, %eax
	jb loop

When I read the timestamp («rdtsc»), a value is returned to edx:eax. This 
code works just fine when I put it in the process stack. The problem is when 
I want to compare %edx instead of %eax, that is:

	rdtsc
	movl %edx, %ecx
	addl $0x1, %ecx
   loop:
	rdtsc
	cmp %ecx, %edx
	jb loop

This is supposed to take much more time than the other loop. When I write 
this code to the stack of my process, a segmentation fault occurs after some 
time. Why? I'm not changing the stack at any moment! (By the way, the stack 
pointer is pointing to the end of my code...)

-- 
Luís Henriques

Re: copy to suer space

[H. Peter Anvin]

Followup to:  <200111231440.fANEeh213167@criticalsoftware.com>
By author:    =?iso-8859-1?q?Lu=EDs=20Henriques?= 
	<lhenriques@criticalsoftware.com>
In newsgroup: linux.dev.kernel
> 
> When I read the timestamp («rdtsc»), a value is returned to edx:eax. This 
> code works just fine when I put it in the process stack. The problem is when 
> I want to compare %edx instead of %eax, that is:
> 
> 	rdtsc
> 	movl %edx, %ecx
> 	addl $0x1, %ecx
>    loop:
> 	rdtsc
> 	cmp %ecx, %edx
> 	jb loop
> 
> This is supposed to take much more time than the other loop. When I write 
> this code to the stack of my process, a segmentation fault occurs after some 
> time. Why? I'm not changing the stack at any moment! (By the way, the stack 
> pointer is pointing to the end of my code...)
> 

Did you remember to restore all the registers, including %eax and
%eflags, before you return?

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: copy to suer space

[Anton Altaparmakov]

At 17:08 20/11/01, Luís Henriques wrote:
>When I'm modifing the code, I'm sure that the page is in memory because my
>code is called from the user space, in the exact location where I want to
>change it (with a breakpoint interruption...)

There is a time window in which it might get paged out in the mean time but 
it's admittedly a very small window. But that is irrelevant as copy_to_user 
would take care of the page out case by faulting the page back in (that is 
at least my understanding of it).

But that is not the problem I was talking about: Imagine you do 
successfully modify the user space code and AFTER THAT the kernel pages out 
the code and pages it back in later. Your change is then lost without trace.

That can easily crash your program depending on what modifications you do 
to it...

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: copy to suer space

[Luís Henriques]

> There is a time window in which it might get paged out in the mean time but
> it's admittedly a very small window. But that is irrelevant as copy_to_user
> would take care of the page out case by faulting the page back in (that is
> at least my understanding of it).
>
> But that is not the problem I was talking about: Imagine you do
> successfully modify the user space code and AFTER THAT the kernel pages out
> the code and pages it back in later. Your change is then lost without
> trace.
>
> That can easily crash your program depending on what modifications you do
> to it...
>
> Anton

I don't understand... this means that the paging does not save the a code 
segment in memory? (sorry, this question is being done by a newbie...) When a 
page is back to memory, what happens? Is read again from the binary file 
(executable)?

Well... I don't think this will have much impact in my module because what it 
does is:

 - change the code in a process
 - return to the process
 - next time the process is scheduled, the code will be stored again in the CS

So, I don't think that the paging will really became a problem as this shall 
be quiet fast! The idea of changing the code is just to insert a delay in a 
process, but leaving the process «burning» CPU time...

The point is: I'm not changing the code because of an obscure (to me...) 
reason. You told me that the code segment may be protected and I'm 
investigating on that but I would like to be sure that the kernel has no 
acess to a user CS...

-- 
Luís Henriques

Re: copy to suer space

[Nick LeRoy]

On Tuesday 20 November 2001 11:53, Luís Henriques wrote:
> > There is a time window in which it might get paged out in the mean time
> > but it's admittedly a very small window. But that is irrelevant as
> > copy_to_user would take care of the page out case by faulting the page
> > back in (that is at least my understanding of it).
> >
> > But that is not the problem I was talking about: Imagine you do
> > successfully modify the user space code and AFTER THAT the kernel pages
> > out the code and pages it back in later. Your change is then lost without
> > trace.
> >
> > That can easily crash your program depending on what modifications you do
> > to it...
> >
> > Anton
>
> I don't understand... this means that the paging does not save the a code
> segment in memory? (sorry, this question is being done by a newbie...) When
> a page is back to memory, what happens? Is read again from the binary file
> (executable)?
>
> Well... I don't think this will have much impact in my module because what
> it does is:
>
>  - change the code in a process
>  - return to the process
>  - next time the process is scheduled, the code will be stored again in the
> CS
>
> So, I don't think that the paging will really became a problem as this
> shall be quiet fast! The idea of changing the code is just to insert a
> delay in a process, but leaving the process «burning» CPU time...
>
> The point is: I'm not changing the code because of an obscure (to me...)
> reason. You told me that the code segment may be protected and I'm
> investigating on that but I would like to be sure that the kernel has no
> acess to a user CS...

Linux executables are "demand paged".  What this means is that they are 
loaded as they are "page faulted" in.  If low on memory, the kernel may, at 
it's discression, discard text pages at any time.  When a discarded page is 
referenced, a page fault occurs, and the page is re-loaded from the 
executable.  They are *never* written out to swap space.  The kernel fully 
expects the text file and the text memory pages to not be modified during 
execution.

-Nick

Re: copy to suer space

[Andreas Bombe]

On Tue, Nov 20, 2001 at 05:53:24PM +0000, Luís Henriques wrote:
> I don't understand... this means that the paging does not save the a code 
> segment in memory? (sorry, this question is being done by a newbie...) When a 
> page is back to memory, what happens? Is read again from the binary file 
> (executable)?

Code and data pages are mapped from the executable.  Code is read-only
and can therefore be discarded at any time, since it exists on disk (in
the executable file, no swap needed).  Data is mapped copy-on-write
(read-only pages until writes occur, then a writable copy is generated).

So only modified data pages and new mappings not backed by a disk file
need to be saved in swap space.

> Well... I don't think this will have much impact in my module because what it 
> does is:
> 
>  - change the code in a process
>  - return to the process
>  - next time the process is scheduled, the code will be stored again in the CS

I'm not sure why you would want to actually _change_ code.  You could
prepare a page in kernel with the busy loop and map that into user
space.

Then make the kernel return to your busy loop and let it call back to
the kernel again when finished, then remove the mapping to leave no
traces.  Maybe that could be done by redirecting a signal handler
pointer and raising that signal.

I don't know how difficult that is, it's just an idea.  But it sure
sounds easier than modifying a read-only page without side effects.

-- 
Andreas Bombe <bombe@informatik.tu-muenchen.de>    DSA key 0x04880A44

Re: copy to suer space

[Luís Henriques]

I remembered something: could it be just a problem with the cache? I mean, 
I'm reading a cache with invalid data...

-- 
Luís Henriques

copy to suer space

[Luis Miguel Correia Henriques]

Hi,
I'm trying to implement a kernel module that will be changing a user
process' code segment. I tried to user copy_to_user to patch the process's
code but, when I tried to read the new code (just to check...), it didn't
worked. Why was that? And what is the solution?

Thanks

Luis Henriques