page permissions

[yemista]

Why do directories and tables have permission bits? If I understand correctly, it should be for when you want to read and write to the directories. So if thats true, does that mean that generally your directories and tables should always have supervisor permissions? I cant see anything in user space ever touching the tables, so only frames should ever be marked as user and write/read?

[kop99]

Hi, yemista.
Generally, process has own pagedirectory and virtual address space.
Some of them is user virtual address space (like 0~3G) and some of them is kernel vertual address space(normally, 3G~4G).
Then, process only read/write it's own user virtual address space.

[Brendan]

Hi,

Why do directories and tables have permission bits? If I understand correctly, it should be for when you want to read and write to the directories. So if thats true, does that mean that generally your directories and tables should always have supervisor permissions? I cant see anything in user space ever touching the tables, so only frames should ever be marked as user and write/read?

For CPL=3 code to access anything, the permission flags at all levels (e.g. in the page table *and* in the page directory) must allow it. For example, if your page directory entries always have supervisor permissions, then CPL=3 code won't be able to access anything at all.

For user space you should probably set the permissions in the page directory entries to allow everything (and then use the permissions in the page table entries to control access), and for kernel space you should probably set the permissions in the page directory entries to "supervisor" (so that even if you accidentally mess up the permissions in the page table entries for kernel space, user level code won't be able to access anything).

It is possible to set the permissions in all page directory entries to allow everything. In this case you'd only need to worry about the permissions in page table entries (which may be easier). However, in this case if you do the self-reference thing (create a page directory entry that refers to the page directory, to create a 4 MiB mapping of page table entries in the virtual address space) then you must make sure that this page directory entry is "supervisor", even if all other page directory entries allow everything (otherwise user level code could modify the page tables, etc).

Also note that for large pages (e.g. 2 MiB pages with PAE) there are no page table entries, so the permission bits in the page directory entry may be the only permission bits you can use (there are no permission bits in the page directory pointer table entries for PAE).

Lastly, for long mode there's 4 sets of permission bits for 4 KiB pages, and 3 sets of permission bits for 2 MiB pages (e.g. in the PML4 entries, in the PDP entries, in the PD entries and in the PT entries). I'd be very tempted to only use the permission bits at the highest and lowest levels in this case (e.g. for 4 KiB pages, always set the permission bits in the PDP entries and PD entries to allow everything, and only use the permission bits in the PML4 entries and the PT entries to control access).

If you think this is a little silly, cache control flags in the paging structures are worse (for 4 KiB pages in long mode, there's 5 sets of flags that effect caching - one set of flags at each level beginning with the flags in CR3)...



Cheers,

Brendan

[yemista]

Ok, I think I see what you mean. So if we have 3 levels, directory, table, page, if i set the permissions for directory and table to be user and read, then user mode will be able to read addresses that mapped into that directory? And if I want users to write to a specific page, i make that page's permissions to be write, but leave the directory and table that the page belongs to as read? Or do permissions bubble up? So for example, if the page is marked as write, but the table is marked as read, and you try to write to the page, since the page is in the table marked as read, even through the page is marked as write, you will get a page fault by trying to write to a page in a read only table. This is where my confusion is.

[Combuster]

You need all levels to grant a certain privilege or else it will be denied.

[yemista]

So how does copy on write work? I guess I shouldve started with that because thats what brought up the question. Lets say you fork a process, clone the tables, and mark the frames as copy on write and read. The old process was only about 12k so it only has 3 pages mapped, all of them mapped as read. You mark the page table and directory as user and read in the new process. Now the new process tries to write to a page, a fault occurs, we copy the frame, and then mark that page as write now. However, the other two pages, the table, and the directory are all still marked as read, so will the process still be able to write to the page that is now marked as write? Or is the way to do this to mark the directory and the table as user and write, and mark the pages as user and read to prevent anyone writing to the pages?

[Brendan]

Hi,

Or is the way to do this to mark the directory and the table as user and write, and mark the pages as user and read to prevent anyone writing to the pages?

That sounds like the right option to me (although you'd need other stuff too - e.g. a reference count for each page so you know how many processes are still using copies of it).


Cheers,

Brendan

[yemista]

That sounds like the right option to me (although you'd need other stuff too - e.g. a reference count for each page so you know how many processes are still using copies of it).

Ah, thats were the difficulty lies. I knew it couldnt be as easy as I thought. Back to the drawing board. Thank you!