This can be done by using different regions for read and write access. For tasks where the write-protection is neccesary, a page is mapped only to the writeable area if the page is writable in the page-table.
The task is to find all relevant writes in the current version.
Seb
-----Original Message----- From: Michael Hohmuth [mailto:hohmuth@innocent.com] Sent: Mittwoch, 7. November 2001 12:35 To: jhuntnz@users.sourceforge.net Cc: l4-hackers@os.inf.tu-dresden.de Subject: Re: l4 for 386
Jonathan Hunt jhuntnz@users.sourceforge.net writes:
Yes I would but interested in porting this to a 386. Could anyone give me some more information on what would be required to change. (The FAQ is rather brief). I understand the the CR0::WP bit enables an exception when a fully privileged task (such as the kernel task) writes to a read-only page but when does this happen that I can check explicitly for it?
Offhand I can think of two places that rely on page faults when writing to write-protected pages:
When reading from a nonexisting thread's thread-control block (TCB), the TCB's virtual-memory region is backed by a read-only zero-filled page. This page gets replaced with a newly-allocated page only when a write access occurs. This mechanism is intended to prevent malicious threads from causing the kernel to allocate hundreds of pages by attempting to send IPC to (or otherwise modify) nonexisting threads.
In a first 386 version, this protection mechanism can just
be disabled.
- In memory-copying IPC operations (and some other operations that write to the user address space, like exception delivery),
the kernel relies on page faults when accessing write-protected user pages.
This could be approximated by checking for write permission in the copy operation, like Linux does.
Michael
hohmuth@innocent.com, hohmuth@inf.tu-dresden.de http://home.pages.de/~hohmuth/ _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
[Sebastian Schoenberg]
This can be done by using different regions for read and write access. For tasks where the write-protection is neccesary, a page is mapped only to the writeable area if the page is writable in the page-table.
I'm not sure I know what you mean here. Are you suggesting that we divide the user-accessible virtual memory into two equally sized mirrored regions; one for read-only and one for read-write?
eSk
The way we did that in BirliX is to "copy on read" and "fold on store back"). I.e., when a page is not needed any more in main memory, the pager is asked to either store it as is it or to reestablish cow sharing. But a bit complicated and requires cooperation of pagers. --hermann
l4-hackers@os.inf.tu-dresden.de