[Question] A question about arm64 pte

[Question] A question about arm64 pte

[Yisheng Xie]

hi,
I have question about arm64 pte.

For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
and PTE_DIRTY is to mark whether the page is dirty.
However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.

Is that means that the page is still writable when PTE_RDONLY is set with PTE_WRITE?
But in ARM Architecture Reference Manual for ARMv8,
when PTE_RDONLY is set(AP[2:1] = 0b1x), Acess from EL1 is Ready only?

so what is the really means of the PTE_RDONLY? could some one help to explain it?

Thanks
Yisheng Xie

[Question] A question about arm64 pte

[Catalin Marinas]

On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
> I have question about arm64 pte.

I assume the context is ARMv8.0 (without hardware DBM support).

> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
> and PTE_DIRTY is to mark whether the page is dirty.
> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.

That's what set_pte_at() does.

> Is that means that the page is still writable when PTE_RDONLY is set with PTE_WRITE?

No. On ARMv8.0, PTE_WRITE is a software only bit while PTE_RDONLY
describes the actual hardware permission. If set_pte_at() does not clear
the PTE_RDONLY bit (PTE_DIRTY not set), the page is read-only even
though PTE_WRITE may be set.

> But in ARM Architecture Reference Manual for ARMv8,
> when PTE_RDONLY is set(AP[2:1] = 0b1x), Acess from EL1 is Ready only?

Yes.

> so what is the really means of the PTE_RDONLY?

Read-only. On ARMv8.0, PTE_WRITE is irrelevant from a hardware
perspective.

-- 
Catalin

[Question] A question about arm64 pte

[Yisheng Xie]

hi Catalin,
Thank you so much for you reply.

On 2017/1/16 19:56, Catalin Marinas wrote:
> On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
>> I have question about arm64 pte.
> 
> I assume the context is ARMv8.0 (without hardware DBM support).

Yes.
> 
>> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
>> and PTE_DIRTY is to mark whether the page is dirty.
>> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
> 
> That's what set_pte_at() does.
> 

So if we mmap a memory region use /dev/mem like:
   fildes = open("/dev/mem", O_RDWR | O_CREAT, 0777);
   addr = mmap(NULL, LEN, PROT_READ | PROT_WRITE, MAP_SHARED, fildes, offset);

The PTE_RDONLY will be set? Right ?
However?when use memset to write the region it still works well, and the bit PTE_RDONLY is also cleared.
Is there anywhere clear the PTE_RDONLY before write that page ?

Thanks
Yisheng Xie

[Question] A question about arm64 pte

[Steve Capper]

On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
> hi Catalin,
> Thank you so much for you reply.
> 
> On 2017/1/16 19:56, Catalin Marinas wrote:
> > On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
> >> I have question about arm64 pte.
> > 
> > I assume the context is ARMv8.0 (without hardware DBM support).
> 
> Yes.
> > 
> >> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
> >> and PTE_DIRTY is to mark whether the page is dirty.
> >> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
> > 
> > That's what set_pte_at() does.
> > 
> 
> So if we mmap a memory region use /dev/mem like:
>    fildes = open("/dev/mem", O_RDWR | O_CREAT, 0777);
>    addr = mmap(NULL, LEN, PROT_READ | PROT_WRITE, MAP_SHARED, fildes, offset);
> 
> The PTE_RDONLY will be set? Right ?
> However?when use memset to write the region it still works well, and the bit PTE_RDONLY is also cleared.
> Is there anywhere clear the PTE_RDONLY before write that page ?
> 

Hi Yisheng,
Out of interest, why is /dev/mem being accessed directly from userspace?

The case above will have subtley different logic (mmap_mem will affect
how things are actually mapped); which I'm trying to understand...

Cheers,
-- 
Steve

[Question] A question about arm64 pte

[Catalin Marinas]

On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
> On 2017/1/16 19:56, Catalin Marinas wrote:
> > On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
> >> I have question about arm64 pte.
> > 
> > I assume the context is ARMv8.0 (without hardware DBM support).
> 
> Yes.
> > 
> >> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
> >> and PTE_DIRTY is to mark whether the page is dirty.
> >> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
> > 
> > That's what set_pte_at() does.
> > 
> 
> So if we mmap a memory region use /dev/mem like:
>    fildes = open("/dev/mem", O_RDWR | O_CREAT, 0777);
>    addr = mmap(NULL, LEN, PROT_READ | PROT_WRITE, MAP_SHARED, fildes, offset);
> 
> The PTE_RDONLY will be set? Right ?

Possibly, I haven't checked mmap_mem(). However, that's what you would
get with an anonymous mmap() as well.

> However?when use memset to write the region it still works well, and
> the bit PTE_RDONLY is also cleared. Is there anywhere clear the
> PTE_RDONLY before write that page ?

See handle_pte_fault(). On the first access to a writable+clean page
(PTE_WRITE set, PTE_RDONLY set, PTE_DIRTY cleared), the kernel traps it
and, if pte_write() is true (your case), it calls pte_mkdirty(). The
subsequently called ptep_set_access_flags() function would clear
PTE_RDONLY, giving you a writable mapping.

-- 
Catalin

[Question] A question about arm64 pte

[Catalin Marinas]

On Mon, Jan 16, 2017 at 02:36:02PM +0000, Catalin Marinas wrote:
> On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
> > On 2017/1/16 19:56, Catalin Marinas wrote:
> > > On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
> > >> I have question about arm64 pte.
> > > 
> > > I assume the context is ARMv8.0 (without hardware DBM support).
> > 
> > Yes.
> > > 
> > >> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
> > >> and PTE_DIRTY is to mark whether the page is dirty.
> > >> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
> > > 
> > > That's what set_pte_at() does.
> > > 
> > 
> > So if we mmap a memory region use /dev/mem like:
> >    fildes = open("/dev/mem", O_RDWR | O_CREAT, 0777);
> >    addr = mmap(NULL, LEN, PROT_READ | PROT_WRITE, MAP_SHARED, fildes, offset);
> > 
> > The PTE_RDONLY will be set? Right ?
> 
> Possibly, I haven't checked mmap_mem(). However, that's what you would
> get with an anonymous mmap() as well.

A correction on anonymous mmap(): the original page links to a zeroed
page, so when dirtying it you also get a new copy, so slightly different
code path from handle_pte_fault().

-- 
Catalin

[Question] A question about arm64 pte

[Yisheng Xie]

Hi Catalin,

Thanks again for your reply, and I will check the logic once more.

Thanks
Yisheng Xie

On 2017/1/16 22:36, Catalin Marinas wrote:
> On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
>> On 2017/1/16 19:56, Catalin Marinas wrote:
>>> On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
>>>> I have question about arm64 pte.
>>>
>>> I assume the context is ARMv8.0 (without hardware DBM support).
>>
>> Yes.
>>>
>>>> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
>>>> and PTE_DIRTY is to mark whether the page is dirty.
>>>> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
>>>
>>> That's what set_pte_at() does.
>>>
>>
>> So if we mmap a memory region use /dev/mem like:
>>    fildes = open("/dev/mem", O_RDWR | O_CREAT, 0777);
>>    addr = mmap(NULL, LEN, PROT_READ | PROT_WRITE, MAP_SHARED, fildes, offset);
>>
>> The PTE_RDONLY will be set? Right ?
> 
> Possibly, I haven't checked mmap_mem(). However, that's what you would
> get with an anonymous mmap() as well.
> 
>> However?when use memset to write the region it still works well, and
>> the bit PTE_RDONLY is also cleared. Is there anywhere clear the
>> PTE_RDONLY before write that page ?
> 
> See handle_pte_fault(). On the first access to a writable+clean page
> (PTE_WRITE set, PTE_RDONLY set, PTE_DIRTY cleared), the kernel traps it
> and, if pte_write() is true (your case), it calls pte_mkdirty(). The
> subsequently called ptep_set_access_flags() function would clear
> PTE_RDONLY, giving you a writable mapping.
> 

[Question] A question about arm64 pte

[Yisheng Xie]

On 2017/1/16 20:57, Steve Capper wrote:
> On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
>> hi Catalin,
>> Thank you so much for you reply.
>>
>> On 2017/1/16 19:56, Catalin Marinas wrote:
>>> On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
>>>> I have question about arm64 pte.
>>>
>>> I assume the context is ARMv8.0 (without hardware DBM support).
>>
>> Yes.
>>>
>>>> For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
>>>> and PTE_DIRTY is to mark whether the page is dirty.
>>>> However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
>>>
>>> That's what set_pte_at() does.
>>>
>>
>> So if we mmap a memory region use /dev/mem like:
>>    fildes = open("/dev/mem", O_RDWR | O_CREAT, 0777);
>>    addr = mmap(NULL, LEN, PROT_READ | PROT_WRITE, MAP_SHARED, fildes, offset);
>>
>> The PTE_RDONLY will be set? Right ?
>> However?when use memset to write the region it still works well, and the bit PTE_RDONLY is also cleared.
>> Is there anywhere clear the PTE_RDONLY before write that page ?
>>
> 
> Hi Yisheng,
> Out of interest, why is /dev/mem being accessed directly from userspace?
hi Steve,
Thank you for your reply.
We just want to access some reserved memory region.

Thanks
Yisheng Xie.

> 
> The case above will have subtley different logic (mmap_mem will affect
> how things are actually mapped); which I'm trying to understand...
> 
> Cheers,
> 

[Question] A question about arm64 pte

[Yisheng Xie]

On 2017/1/16 22:36, Catalin Marinas wrote:
> On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
>> On 2017/1/16 19:56, Catalin Marinas wrote:
>>> On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
>>>
>> However?when use memset to write the region it still works well, and
>> the bit PTE_RDONLY is also cleared. Is there anywhere clear the
>> PTE_RDONLY before write that page ?
> 
> See handle_pte_fault(). On the first access to a writable+clean page
> (PTE_WRITE set, PTE_RDONLY set, PTE_DIRTY cleared), the kernel traps it
> and, if pte_write() is true (your case), it calls pte_mkdirty(). The
> subsequently called ptep_set_access_flags() function would clear
> PTE_RDONLY, giving you a writable mapping.
> 
hi Catalin?
Sorry to disturb, but why page fault will happened here, for pte already
present with AF bit set?

Here is what I get when mmap a reserved memory region 0x39ef 0000~0x3a00 0000
use /dev/mem:
[  442.704228] pgd = ffff802785f14000
[  442.707641] [ffff86e4b000] *pgd=000000279080c003, *pud=0000002785f01003, *pmd=0000002783f5b003, *pte=0168000039ef0fd3

Thanks,
Yisheng Xie.

[Question] A question about arm64 pte

[Catalin Marinas]

On Tue, Jan 17, 2017 at 11:53:43AM +0800, Yisheng Xie wrote:
> On 2017/1/16 22:36, Catalin Marinas wrote:
> > On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
> >> On 2017/1/16 19:56, Catalin Marinas wrote:
> >>> On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
> >>>
> >> However?when use memset to write the region it still works well, and
> >> the bit PTE_RDONLY is also cleared. Is there anywhere clear the
> >> PTE_RDONLY before write that page ?
> > 
> > See handle_pte_fault(). On the first access to a writable+clean page
> > (PTE_WRITE set, PTE_RDONLY set, PTE_DIRTY cleared), the kernel traps it
> > and, if pte_write() is true (your case), it calls pte_mkdirty(). The
> > subsequently called ptep_set_access_flags() function would clear
> > PTE_RDONLY, giving you a writable mapping.
> 
> Sorry to disturb, but why page fault will happened here, for pte already
> present with AF bit set?
> 
> Here is what I get when mmap a reserved memory region 0x39ef 0000~0x3a00 0000
> use /dev/mem:
> [  442.704228] pgd = ffff802785f14000
> [  442.707641] [ffff86e4b000] *pgd=000000279080c003, *pud=0000002785f01003, *pmd=0000002783f5b003, *pte=0168000039ef0fd3

The pte seems to have bit 7 set: PTE_RDONLY. So you would get a fault on
write (but not read). Since PTE_WRITE is also set, handle_pte_fault()
will mark the entry as dirty (bit 55, cleared above) and clear
PTE_RDONLY before restarting the access instruction. User space wouldn't
notice, just a slight delay on the first access.

-- 
Catalin

[Question] A question about arm64 pte

[Yisheng Xie]

On 2017/1/17 19:45, Catalin Marinas wrote:
> On Tue, Jan 17, 2017 at 11:53:43AM +0800, Yisheng Xie wrote:
>> On 2017/1/16 22:36, Catalin Marinas wrote:
>>> On Mon, Jan 16, 2017 at 08:39:56PM +0800, Yisheng Xie wrote:
>>>> On 2017/1/16 19:56, Catalin Marinas wrote:
>>>>> On Mon, Jan 16, 2017 at 06:08:47PM +0800, Yisheng Xie wrote:
>>>>>
>>
>> Here is what I get when mmap a reserved memory region 0x39ef 0000~0x3a00 0000
>> use /dev/mem:
>> [  442.704228] pgd = ffff802785f14000
>> [  442.707641] [ffff86e4b000] *pgd=000000279080c003, *pud=0000002785f01003, *pmd=0000002783f5b003, *pte=0168000039ef0fd3
> 
> The pte seems to have bit 7 set: PTE_RDONLY. So you would get a fault on
> write (but not read). Since PTE_WRITE is also set, handle_pte_fault()
> will mark the entry as dirty (bit 55, cleared above) and clear
> PTE_RDONLY before restarting the access instruction. User space wouldn't
> notice, just a slight delay on the first access.
> 
Hi Catalin,
Really thank you for kindly explain, quite clear now.

Thanks
Yisheng Xie.