From: "Luís Henriques" <lhenriques@criticalsoftware.com>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: copy to suer space
Date: Tue, 20 Nov 2001 17:53:24 +0000 [thread overview]
Message-ID: <200111201759.fAKHx9289954@criticalsoftware.com> (raw)
In-Reply-To: <5.1.0.14.2.20011120165440.00a745b0@pop.cus.cam.ac.uk> <5.1.0.14.2.20011120173309.0262fd10@pop.cus.cam.ac.uk>
In-Reply-To: <5.1.0.14.2.20011120173309.0262fd10@pop.cus.cam.ac.uk>
> 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
next prev parent reply other threads:[~2001-11-20 17:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.31.0111201637420.13674-100000@mail.deis.isec.pt >
2001-11-20 17:02 ` copy to suer space Anton Altaparmakov
2001-11-20 17:08 ` Luís Henriques
2001-11-20 18:41 ` Andreas Dilger
2001-11-20 18:44 ` Luís Henriques
2001-11-20 18:58 ` Hua Zhong
2001-11-20 19:39 ` Andreas Dilger
2001-11-21 0:06 ` Mike Fedyk
2001-11-21 10:52 ` Luís Henriques
2001-11-23 13:14 ` Juan Quintela
2001-11-23 14:35 ` Luís Henriques
2001-11-23 23:53 ` H. Peter Anvin
2001-11-20 17:37 ` Anton Altaparmakov
2001-11-20 17:53 ` Luís Henriques [this message]
2001-11-20 18:18 ` Nick LeRoy
2001-11-22 18:51 ` Andreas Bombe
2001-11-20 18:09 ` Luís Henriques
2001-11-21 14:37 Joerg Pommnitz
[not found] <sbfa4d3a.051@MAIL-SMTP.uvsc.edu>
2001-11-21 10:49 ` Luís Henriques
-- strict thread matches above, loose matches on Subject: below --
2001-11-20 16:40 Luis Miguel Correia Henriques
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200111201759.fAKHx9289954@criticalsoftware.com \
--to=lhenriques@criticalsoftware.com \
--cc=aia21@cam.ac.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.