OSDev.org

Hi,
when creating page directories and tables, we map the table unto itself at entry 1023(0xffc),the last entry. But by doing this, some addresses are now unusable for example
a program, kernal process or user process, can not use
0xFFC7CFFF

How do you guys work around this problem and make sure, processes dont try and access addresses you are using to map your page dirs and tables?

How do you guys work around this problem and make sure, processes dont try and access addresses you are using to map your page dirs and tables?

Hi,
why don't you just mark it as a system page ?
The kernel have access to the pagetables - how else should it map pages in/out ?

regards,
gaf

That wasn't my question. Did you read it?
I asked about restricting processes from generating address that have been used for mapping tables on to themselves.

I also have the same problem to solve before, but I didn't wanted to prevent processes from accessing 0xFFC7CFFF or any "high address". I wanted to prevent them from accessing the two first page tables (0x0 to 0x1FFF).
I simply build up code, data and stack segment above this, so that the process can never access them, as these address are not part of any segment.

In your case, I suggest to set the limit of each segment below your limit.

Hi,
when creating page directories and tables, we map the table unto itself at entry 1023(0xffc),the last entry. But by doing this, some addresses are now unusable for example
a program, kernal process or user process, can not use
0xFFC7CFFF

How do you guys work around this problem and make sure, processes dont try and access addresses you are using to map your page dirs and tables?

This approach does have the drawback you describe, that each process loses the top 4MB of its address space, but the benefits are that:
a) You have the pagetables in known and consecutive locations in virtual memory (and dont have to calculate their locations/map them in when they need to be changed)
and b) You save 4kB (physical memory) per process by having the pagedirectory and a pagetable in the same place

I dont find the need to 'work around' this, I always run out of physical memory before losing 4MB out of 4GB becomes an issue.
(if having an unusable hole at the _end_ of your memory is the problem, move it. Use a different entry in the pagedir for your overlap. You still get both a and b above, and you still have a 4MB hole in your virtual space)

To make sure user processes dont access the pagetables, i use the 'system' flag (as was suggested by gaf before you tried to tell him to read closer)

gaf's reply was fine. Did you read it?

I mark the system pagedir entries (to which the self reference mapping of the pagedirectory belongs) as supervisor: phys address|0x03. This usually does the trick -> the process traps into the page handler and gets killed due to invalid access.

Simple problem - simple solution.

How to prevent kernel threads from accessing this adress area - hm, I don't know yet. Simply don't access it? You as the kernel coder/designer know where the pitfalls are at the end.

@irbme -> gaf surely can speak for him/herself, hm?

Only Beyond infinity understood what I'm referring to, I'm not asking about SYSTEM or USER pages. I've had my paging system working for over a year now. I'm not new at this. (count my stars!)

This usually does the trick -> the process traps into the page handler and gets killed due to invalid access.

Simple problem - simple solution.

This is my current solution, was only trying to see if there were others,even better ones, available.

@Ytinasni:

This approach does have the drawback you describe, that each process loses the top 4MB of its address space, but the benefits are that:........

I think each process actually looses more than 4Mb, cause the 1023th entry in the page dir maps 4MB and then in each table, the 1023th entry maps 4k
so total loss of memory space is
4mb+ (I * 4k) where I is the current number of page tables


Anyway, I hope pype, solar , tim and the rest can give some suggestions. Their discussions are always educational.

honnestly, i don't see why you'd want *kernel threads* away from the directory pages ... After all, how would you allow the kernel to map new pages, otherwise ?

Well, now if you don't trust your kernel enough and want to avoid stupid programming errors, you may tweak the datasegment limit so that the self-mapped directory appears out of it, and provide *another* segment to access directory mapping ... But imho, all that segments stuff is more likely to introduce bugs than removing some of them ...

Only Beyond infinity understood what I'm referring to, I'm not asking about SYSTEM or USER pages.

I don't get it - could anybody please explain me where's the BIG difference between my answer and what beyond infinity said ?

Why don't you just mark it as a system page ?
vs.
I mark the system pagedir entries (to which the self reference mapping of the pagedirectory belongs) as supervisor

If you're problem is that you can't trust your kernel tasks you should switch to a microkernel design.

Anyway, I hope pype, solar , tim and the rest can give some suggestions. Their discussions are always educational.

What's that supposed to mean ?

regards,
gaf

gaf wrote:

Anyway, I hope pype, solar , tim and the rest can give some suggestions. Their discussions are always educational.

What's that supposed to mean ?

maybe that they have much experience and/or been at it for several years?

<footnote>
If Beyond Infinity only understood what you're asking, maybe you could like to rephrase or be more precise at what trouble you ...
</footnote>

a) user-level code direct access to mapped page tables ? protection bits can prevent this.
b) system calls blindly using userlevel-passed args ? add a software check to make sure userlevel-pointers are valid userlevel memory areas.
c) kernel code messing up mapped page tables ? you can only make this harder to write by error, but you cannot block it (imho)

@gaf: *shrugs* besides using a different wording, there's really no difference. *gg*

Besides, I'm doing the microkernel thing, and I don't mind having "kernel tasks" which might produce faulty addresses - then, that's only my fault to make this happen - so no blame to the paging subsystem in such a case.

@bubach: well, you're most probably right. )