Hello Okash,
Actually there were 3 question:
Third question is :
Is there any way to tell the kernel that PTE of same physical page should be
equal in all processes?
For example, shared lib mapped from different processes to same physical page
must have same PTE, isn it?
And the presence of SELinux feature SELINUX_CHECKREQPROT_VALUE indicates for
me that kernel somehow knows the correct page protections. (although I do not
see in code how it is done)
But the question might be rephrased : IMHO Kernel should mandate same PTE
flags no matter how many virtual mapping were made to the same physical page.
What do you think?
21.03.2019, 13:45, "Okash Khawaja" :
> On Thu, 21 Mar 2019 12:56:17 +0300
> Lev Olshvang wrote:
>
>> Hi Vaaldis,
>>
>> Thanks for answer,
>> I still wondering whether the kernel will allow write to a read-only
>> page of shared library while it has mapped to several processes?
>> Kernel knows that page's reference count >1, will it allow
>> mmap/mprotect to change page protection ? Or will it allow direct
>> right by physical address? I suppose that CPU should raise page fault
>> when write is made to read only page,
>>
>> What is the sequence CPU raises page faul before write to page of
>> after data is written Will CPU wait until kernel will consider what
>> to do , whether agree and change PTE "writable " bit to 1 ? Or
>> kernel may disagree and raise SEGFAULT?
>
> Note that each process has its own PTE. So PTE in one process may say
> the page is writable and PTE in another process may say it's read-only.
>
>> I checked in the handle_mm_fault() calls for
>> arch_vma_access_permitted() which just returns true on most
>> architectures which is very strange and contradicts my prediction of
>> SEFFAULT. arch_vma_access_permitted() retutus true when is sees that
>> access is made from foreign process?
>> https://elixir.bootlin.com/linux/latest/ident/arch_vma_access_permitted
>>
>> I am totally confused.
>>
>> What do you think ?
>>
>> Regards,
>> Lev
>
> It looks like there are two separate questions in the email.
>
> 1) Will kernel allow the same physical page to be mapped as read-only
> in one process and as read-write in another process?
>
> 2) How page fault is generated?
>
> Answer for first is yes. Same physical page can be mapped with
> different permissions in two different processes. It means read-only
> process will ultimately (hopefully very soon) notice changes made by
> read-write process.
>
> Answer for second question is a bit complicated. However there is a
> trick to it. Once we know that, rest will become clear automaticaly.
> The trick (at least for x86 systems) is that permissions are maintained
> at two different levels:
>
> - VMA level
> - PTE level (or PUD level for larger page size but that is not relevant
> here)
>
> When a page in memory is accessed, permission on corresponding VMA is
> checked first. If the access is allowed by VMA then PTE permissions are
> checked. Otherwise segfault is generated. If permissions at PTE level
> don't match the access type then a page fault is generated. That's when
> page fault hander kicks in and tries to resolve the problem by faulting
> the page into RAM, copying the page in RAM (for copy-on-write) etc.
>
>> 20.03.2019, 20:08, "Valdis Klētnieks" :
>> > On Wed, 20 Mar 2019 16:42:39 +0300, Lev Olshvang said:
>> >> The question is it ipossiblle in Linux/MMU/TLB that 2 processes
>> >> map to the same physical address?
>> >
>> > Totally possible. That's how mmap shared memory works, and why
>> > shared libraries are possible.
>> >
>> >> Will CPU or TLB discover that second process tries to reach
>> >> occupied physical page?
>> >
>> > Well, the hardware won't discover it as a "second" process, it only
>> > knows it's processing *this* memory access.
>> >
>> >> What if first process set page permission to read and second
>> >> whats to write to this page ?
>> >
>> > Perfectly OK - the two processes have separate page table mappings,
>> > with separate permission bits. So (for example) physical page
>> > 0x17F000 is mapped to virtual address 0x2034D000 with read-only
>> > permission n process 1's page tables, and to virtual address
>> > 0x98FF3000 with read-write permission in process 2's page tables.
>> > No problem.
>> >
>> > (And before you ask, yes it's possible for process 2 to running on
>> > one core doing a write to the page at the exact same time that
>> > process 1 is doing a read on another core. Depending on the
>> > hardware cache design, this may or may not get process 1 updated
>> > data. This is why locking and memory barriers are important. See
>> > Documentation/memory-barriers.txt for more details)
>> >
>> > "And then there's the Alpha" - a processor design that got much of
>> > its speed by being weird about this stuff. :)
>> >
>> >> Perhaps during context switch all page access permissions of
>> >> first process is flashed out from
