Re: [bug?] Access was denied by memory protection keys in execute-only address

Re: [bug?] Access was denied by memory protection keys in execute-only address

[Michael Ellerman]

Li Wang <liwang@redhat.com> writes:
> Hi,
>
> ltp/mprotect04[1] crashed by SEGV_PKUERR on ppc64(LPAR on P730, Power 8
> 8247-22L) with kernel-v4.16.0-rc4.
>
> 10000000-10020000 r-xp 00000000 fd:00 167223           mprotect04
> 10020000-10030000 r--p 00010000 fd:00 167223           mprotect04
> 10030000-10040000 rw-p 00020000 fd:00 167223           mprotect04
> 1001a380000-1001a3b0000 rw-p 00000000 00:00 0          [heap]
> 7fffa6c60000-7fffa6c80000 --xp 00000000 00:00 0 =E2=80=8B
>
> =E2=80=8B&exec_func =3D 0x10030170=E2=80=8B
>
> =E2=80=8B&func =3D 0x7fffa6c60170=E2=80=8B
>
> =E2=80=8BWhile perform =E2=80=8B
> "(*func)();" we get the
> =E2=80=8Bsegmentation fault.
> =E2=80=8B
>
> =E2=80=8Bstrace log:=E2=80=8B
>
> -------------------
> =E2=80=8Bmprotect(0x7fffaed00000, 131072, PROT_EXEC) =3D 0
> rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  =3D 0
> --- SIGSEGV {si_signo=3DSIGSEGV, si_code=3DSEGV_PKUERR, si_addr=3D0x7fffa=
ed00170}
> ---=E2=80=8B

Looks like a bug to me.

Please Cc linuxppc-dev on powerpc bugs.

I also can't reproduce this failure on my machine.
Not sure what's going on?

cheers

Re: [bug?] Access was denied by memory protection keys in execute-only address

[Ram Pai]

On Thu, Mar 08, 2018 at 11:19:12PM +1100, Michael Ellerman wrote:
> Li Wang <liwang@redhat.com> writes:
> > Hi,
> >
> > ltp/mprotect04[1] crashed by SEGV_PKUERR on ppc64(LPAR on P730, Power 8
> > 8247-22L) with kernel-v4.16.0-rc4.
> >
> > 10000000-10020000 r-xp 00000000 fd:00 167223           mprotect04
> > 10020000-10030000 r--p 00010000 fd:00 167223           mprotect04
> > 10030000-10040000 rw-p 00020000 fd:00 167223           mprotect04
> > 1001a380000-1001a3b0000 rw-p 00000000 00:00 0          [heap]
> > 7fffa6c60000-7fffa6c80000 --xp 00000000 00:00 0 ​
> >
> > ​&exec_func = 0x10030170​
> >
> > ​&func = 0x7fffa6c60170​
> >
> > ​While perform ​
> > "(*func)();" we get the
> > ​segmentation fault.
> > ​
> >
> > ​strace log:​
> >
> > -------------------
> > ​mprotect(0x7fffaed00000, 131072, PROT_EXEC) = 0
> > rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
> > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_PKUERR, si_addr=0x7fffaed00170}
> > ---​
> 
> Looks like a bug to me.
> 
> Please Cc linuxppc-dev on powerpc bugs.
> 
> I also can't reproduce this failure on my machine.
> Not sure what's going on?

I could reproduce it on a power7 lpar.  But not on a power8 lpar.

The problem seems to be that the cpu generates a key exception if
the page with Read/Write-disable-but-execute-enable key is executed
on power7. If I enable read on that key, the exception disappears.

BTW: the testcase executes mprotect(..,PROT_EXEC).
The mprotect(, PROT_EXEC) system call internally generates a
execute-only key and associates it with the pages in the address-range.

Now since Li Wang claims that he can reproduce it on power8 as well, i
am wondering if the slightly different cpu behavior is dependent on the
version of the firmware/microcode?


RP

Re: [bug?] Access was denied by memory protection keys in execute-only address

[Li Wang]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

On Fri, Mar 9, 2018 at 12:45 AM, Ram Pai <linuxram@us.ibm.com> wrote:

> On Thu, Mar 08, 2018 at 11:19:12PM +1100, Michael Ellerman wrote:
> > Li Wang <liwang@redhat.com> writes:
> > > Hi,
> > >
> > > ltp/mprotect04[1] crashed by SEGV_PKUERR on ppc64(LPAR on P730, Power 8
> > > 8247-22L) with kernel-v4.16.0-rc4.
> > >
> > > 10000000-10020000 r-xp 00000000 fd:00 167223           mprotect04
> > > 10020000-10030000 r--p 00010000 fd:00 167223           mprotect04
> > > 10030000-10040000 rw-p 00020000 fd:00 167223           mprotect04
> > > 1001a380000-1001a3b0000 rw-p 00000000 00:00 0          [heap]
> > > 7fffa6c60000-7fffa6c80000 --xp 00000000 00:00 0 ​
> > >
> > > ​&exec_func = 0x10030170​
> > >
> > > ​&func = 0x7fffa6c60170​
> > >
> > > ​While perform ​
> > > "(*func)();" we get the
> > > ​segmentation fault.
> > > ​
> > >
> > > ​strace log:​
> > >
> > > -------------------
> > > ​mprotect(0x7fffaed00000, 131072, PROT_EXEC) = 0
> > > rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
> > > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_PKUERR,
> si_addr=0x7fffaed00170}
> > > ---​
> >
> > Looks like a bug to me.
> >
> > Please Cc linuxppc-dev on powerpc bugs.
> >
> > I also can't reproduce this failure on my machine.
> > Not sure what's going on?
>
> I could reproduce it on a power7 lpar.  But not on a power8 lpar.
>
> The problem seems to be that the cpu generates a key exception if
> the page with Read/Write-disable-but-execute-enable key is executed
> on power7. If I enable read on that key, the exception disappears.
>

After adding read permission on that key, reproducer get PASS on my power8
machine too.​
​(​mprotect(..,PROT_READ | PROT_EXEC))​



>
> BTW: the testcase executes
> ​​
> mprotect(..,PROT_EXEC).
> The mprotect(, PROT_EXEC) system call internally generates a
> execute-only key and associates it with the pages in the address-range.


> Now since Li Wang claims that he can reproduce it on power8 as well, i
> am wondering if the slightly different cpu behavior is dependent on the
> version of the firmware/microcode?
>

​I also run this reproducer on series ppc kvm machines, but none of them
get the FAIL.
If you need some more HW info, pls let me know.​



>
>
> RP
>
>


-- 
Li Wang
liwang@redhat.com

[-- Attachment #2: Type: text/html, Size: 4275 bytes --]

Re: [bug?] Access was denied by memory protection keys in execute-only address

[Ram Pai]

On Fri, Mar 09, 2018 at 11:43:00AM +0800, Li Wang wrote:
>    On Fri, Mar 9, 2018 at 12:45 AM, Ram Pai <[1]linuxram@us.ibm.com> wrote:
> 
>      On Thu, Mar 08, 2018 at 11:19:12PM +1100, Michael Ellerman wrote:
>      > Li Wang <[2]liwang@redhat.com> writes:
>      > > Hi,
>      > >
>      > > ltp/mprotect04[1] crashed by SEGV_PKUERR on ppc64(LPAR on P730,
>      Power 8
>      > > 8247-22L) with kernel-v4.16.0-rc4.
>      > >
>      > > 10000000-10020000 r-xp 00000000 fd:00 167223           mprotect04
>      > > 10020000-10030000 r--p 00010000 fd:00 167223           mprotect04
>      > > 10030000-10040000 rw-p 00020000 fd:00 167223           mprotect04
>      > > 1001a380000-1001a3b0000 rw-p 00000000 00:00 0          [heap]
>      > > 7fffa6c60000-7fffa6c80000 --xp 00000000 00:00 0 ​
>      > >
>      > > ​&exec_func = 0x10030170​
>      > >
>      > > ​&func = 0x7fffa6c60170​
>      > >
>      > > ​While perform ​
>      > > "(*func)();" we get the
>      > > ​segmentation fault.
>      > > ​
>      > >
>      > > ​strace log:​
>      > >
>      > > -------------------
>      > > ​mprotect(0x7fffaed00000, 131072, PROT_EXEC) = 0
>      > > rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
>      > > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_PKUERR,
>      si_addr=0x7fffaed00170}
>      > > ---​
>      >
>      > Looks like a bug to me.
>      >
>      > Please Cc linuxppc-dev on powerpc bugs.
>      >
>      > I also can't reproduce this failure on my machine.
>      > Not sure what's going on?
> 
>      I could reproduce it on a power7 lpar.  But not on a power8 lpar.
> 
>>      The problem seems to be that the cpu generates a key exception if
>>      the page with Read/Write-disable-but-execute-enable key is executed
>>      on power7. If I enable read on that key, the exception disappears.
>> 
>    After adding read permission on that key, reproducer get PASS on my power8
>    machine too.​
>    ​(​mprotect(..,PROT_READ | PROT_EXEC))​

I enabled READ permission on the key by resetting the bit in
the AMR register.  And that healed the problem. So the point is
something is erroneously triggering the MMU to generate a key-exception
if the READ permission on the key is disabled.

>     
> 
>      BTW: the testcase executes
>      ​​mprotect(..,PROT_EXEC).
>      The mprotect(, PROT_EXEC) system call internally generates a
>      execute-only key and associates it with the pages in the address-range. 
> 
>      Now since Li Wang claims that he can reproduce it on power8 as well, i
>      am wondering if the slightly different cpu behavior is dependent on the
>      version of the firmware/microcode?
> 
>    ​I also run this reproducer on series ppc kvm machines, but none of them
>    get the FAIL.

on ppc kvm virtual-machines the pkey subsystem is not entirely enabled
yet. Though the kernel code exists it does not get enabled, since the
feature is not yet exported in the device-tree by qemu. 

>    If you need some more HW info, pls let me know.​

Will do thanks.
RP

Re: [bug?] Access was denied by memory protection keys in execute-only address

[Ram Pai]

On Fri, Mar 09, 2018 at 11:43:00AM +0800, Li Wang wrote:
>    On Fri, Mar 9, 2018 at 12:45 AM, Ram Pai <[1]linuxram@us.ibm.com> wrote:
> 
>      On Thu, Mar 08, 2018 at 11:19:12PM +1100, Michael Ellerman wrote:
>      > Li Wang <[2]liwang@redhat.com> writes:
>      > > Hi,
>      > >
>      > > ltp/mprotect04[1] crashed by SEGV_PKUERR on ppc64(LPAR on P730,
>      Power 8
>      > > 8247-22L) with kernel-v4.16.0-rc4.
>      > >
>      > > 10000000-10020000 r-xp 00000000 fd:00 167223           mprotect04
>      > > 10020000-10030000 r--p 00010000 fd:00 167223           mprotect04
>      > > 10030000-10040000 rw-p 00020000 fd:00 167223           mprotect04
>      > > 1001a380000-1001a3b0000 rw-p 00000000 00:00 0          [heap]
>      > > 7fffa6c60000-7fffa6c80000 --xp 00000000 00:00 0 ​
>      > >
>      > > ​&exec_func = 0x10030170​
>      > >
>      > > ​&func = 0x7fffa6c60170​
>      > >
>      > > ​While perform ​
>      > > "(*func)();" we get the
>      > > ​segmentation fault.
>      > > ​
>      > >
>      > > ​strace log:​
>      > >
>      > > -------------------
>      > > ​mprotect(0x7fffaed00000, 131072, PROT_EXEC) = 0
>      > > rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
>      > > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_PKUERR,
>      si_addr=0x7fffaed00170}
>      > > ---​
>      >
>      > Looks like a bug to me.
>      >
>      > Please Cc linuxppc-dev on powerpc bugs.
>      >
>      > I also can't reproduce this failure on my machine.
>      > Not sure what's going on?
> 
>      I could reproduce it on a power7 lpar.  But not on a power8 lpar.
> 
>      The problem seems to be that the cpu generates a key exception if
>      the page with Read/Write-disable-but-execute-enable key is executed
>      on power7. If I enable read on that key, the exception disappears.
> 
>    After adding read permission on that key, reproducer get PASS on my power8
>    machine too.​
>    ​(​mprotect(..,PROT_READ | PROT_EXEC))​
>     
> 
>      BTW: the testcase executes
>      ​​mprotect(..,PROT_EXEC).
>      The mprotect(, PROT_EXEC) system call internally generates a
>      execute-only key and associates it with the pages in the address-range. 
> 
>      Now since Li Wang claims that he can reproduce it on power8 as well, i
>      am wondering if the slightly different cpu behavior is dependent on the
>      version of the firmware/microcode?
> 
>    ​I also run this reproducer on series ppc kvm machines, but none of them
>    get the FAIL.
>    If you need some more HW info, pls let me know.​

Hi Li,

   Can you try the following patch and see if it solves your problem.


diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
index c269817..184a10a 100644
--- a/arch/powerpc/mm/pkeys.c
+++ b/arch/powerpc/mm/pkeys.c
@@ -421,7 +421,7 @@ int __arch_override_mprotect_pkey(struct vm_area_struct *vma, int prot,
 	 * The requested protection is execute-only. Hence let's use an
 	 * execute-only pkey.
 	 */
-	if (prot == PROT_EXEC) {
+	if (prot == PROT_EXEC && pkey_execute_disable_supported) {
 		pkey = execute_only_pkey(vma->vm_mm);
 		if (pkey > 0)
 			return pkey;


Thanks
RP

Re: [bug?] Access was denied by memory protection keys in execute-only address

[Li Wang]

[-- Attachment #1: Type: text/plain, Size: 5039 bytes --]

On Wed, Mar 21, 2018 at 5:58 AM, Ram Pai <linuxram@us.ibm.com> wrote:

> On Fri, Mar 09, 2018 at 11:43:00AM +0800, Li Wang wrote:
> >    On Fri, Mar 9, 2018 at 12:45 AM, Ram Pai <[1]linuxram@us.ibm.com>
> wrote:
> >
> >      On Thu, Mar 08, 2018 at 11:19:12PM +1100, Michael Ellerman wrote:
> >      > Li Wang <[2]liwang@redhat.com> writes:
> >      > > Hi,
> >      > >
> >      > > ltp/mprotect04[1] crashed by SEGV_PKUERR on ppc64(LPAR on P730,
> >      Power 8
> >      > > 8247-22L) with kernel-v4.16.0-rc4.
> >      > >
> >      > > 10000000-10020000 r-xp 00000000 fd:00 167223
>  mprotect04
> >      > > 10020000-10030000 r--p 00010000 fd:00 167223
>  mprotect04
> >      > > 10030000-10040000 rw-p 00020000 fd:00 167223
>  mprotect04
> >      > > 1001a380000-1001a3b0000 rw-p 00000000 00:00 0          [heap]
> >      > > 7fffa6c60000-7fffa6c80000 --xp 00000000 00:00 0 ​
> >      > >
> >      > > ​&exec_func = 0x10030170​
> >      > >
> >      > > ​&func = 0x7fffa6c60170​
> >      > >
> >      > > ​While perform ​
> >      > > "(*func)();" we get the
> >      > > ​segmentation fault.
> >      > > ​
> >      > >
> >      > > ​strace log:​
> >      > >
> >      > > -------------------
> >      > > ​mprotect(0x7fffaed00000, 131072, PROT_EXEC) = 0
> >      > > rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
> >      > > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_PKUERR,
> >      si_addr=0x7fffaed00170}
> >      > > ---​
> >      >
> >      > Looks like a bug to me.
> >      >
> >      > Please Cc linuxppc-dev on powerpc bugs.
> >      >
> >      > I also can't reproduce this failure on my machine.
> >      > Not sure what's going on?
> >
> >      I could reproduce it on a power7 lpar.  But not on a power8 lpar.
> >
> >      The problem seems to be that the cpu generates a key exception if
> >      the page with Read/Write-disable-but-execute-enable key is executed
> >      on power7. If I enable read on that key, the exception disappears.
> >
> >    After adding read permission on that key, reproducer get PASS on my
> power8
> >    machine too.​
> >    ​(​mprotect(..,PROT_READ | PROT_EXEC))​
> >
> >
> >      BTW: the testcase executes
> >      ​​mprotect(..,PROT_EXEC).
> >      The mprotect(, PROT_EXEC) system call internally generates a
> >      execute-only key and associates it with the pages in the
> address-range.
> >
> >      Now since Li Wang claims that he can reproduce it on power8 as
> well, i
> >      am wondering if the slightly different cpu behavior is dependent on
> the
> >      version of the firmware/microcode?
> >
> >    ​I also run this reproducer on series ppc kvm machines, but none of
> them
> >    get the FAIL.
> >    If you need some more HW info, pls let me know.​
>
> Hi Li,
>
>    Can you try the following patch and see if it solves your problem.
>

​It only works on power7 lpar machine.

But for p8 lpar, it still get failure as that before, the thing I wondered
is
that why not disable the pkey_execute_disable_supported on p8 machine?

I tried to modify your patch and get PASS with the mprotect04 test on
power8 lpar machine.

--- a/arch/powerpc/mm/pkeys.c
+++ b/arch/powerpc/mm/pkeys.c
@@ -105,7 +105,9 @@ int pkey_initialize(void)
         * The device tree cannot be relied to indicate support for
         * execute_disable support. Instead we use a PVR check.
         */
-       if (pvr_version_is(PVR_POWER7) || pvr_version_is(PVR_POWER7p))
+       if (pvr_version_is(PVR_POWER7) || pvr_version_is(PVR_POWER7p) \
+               || pvr_version_is(PVR_POWER8E) ||
pvr_version_is(PVR_POWER8NVL) \
+               || pvr_version_is(PVR_POWER8))
                pkey_execute_disable_supported = false;
        else
                pkey_execute_disable_supported = true;
@@ -395,7 +397,7 @@ int __arch_override_mprotect_pkey(struct vm_area_struct
*vma, int prot,
         * The requested protection is execute-only. Hence let's use an
         * execute-only pkey.
         */
-       if (prot == PROT_EXEC) {
+       if (prot == PROT_EXEC && pkey_execute_disable_supported) {
                pkey = execute_only_pkey(vma->vm_mm);
                if (pkey > 0)
                        return pkey;




>
>
> diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
> index c269817..184a10a 100644
> --- a/arch/powerpc/mm/pkeys.c
> +++ b/arch/powerpc/mm/pkeys.c
> @@ -421,7 +421,7 @@ int __arch_override_mprotect_pkey(struct
> vm_area_struct *vma, int prot,
>          * The requested protection is execute-only. Hence let's use an
>          * execute-only pkey.
>          */
> -       if (prot == PROT_EXEC) {
> ​​
> +       if (prot == PROT_EXEC && pkey_execute_disable_supported) {
>                 pkey = execute_only_pkey(vma->vm_mm);
>                 if (pkey > 0)
>                         return pkey;
>
>
> Thanks
> RP
>
>


-- 
Li Wang
liwang@redhat.com

[-- Attachment #2: Type: text/html, Size: 7439 bytes --]

Re: [bug?] Access was denied by memory protection keys in execute-only address

[Ram Pai]

On Wed, Mar 21, 2018 at 02:53:00PM +0800, Li Wang wrote:
>    On Wed, Mar 21, 2018 at 5:58 AM, Ram Pai <[1]linuxram@us.ibm.com> wrote:
> 
>      On Fri, Mar 09, 2018 at 11:43:00AM +0800, Li Wang wrote:
>      >    On Fri, Mar 9, 2018 at 12:45 AM, Ram Pai
>      <[1][2]linuxram@us.ibm.com> wrote:
>      >
>      >      On Thu, Mar 08, 2018 at 11:19:12PM +1100, Michael Ellerman wrote:
>      >      > Li Wang <[2][3]liwang@redhat.com> writes:
>      >      > > Hi,
>      >      > >
>      >      am wondering if the slightly different cpu behavior is dependent
..snip..
>      on the
>      >      version of the firmware/microcode?
>      >
>      >    ​I also run this reproducer on series ppc kvm machines, but none of
>      them
>      >    get the FAIL.
>      >    If you need some more HW info, pls let me know.​
> 
>      Hi Li,
> 
>         Can you try the following patch and see if it solves your problem.
> 
>    ​It only works on power7 lpar machine.
> 
>    But for p8 lpar, it still get failure as that before, the thing I wondered
>    is
>    that why not disable the pkey_execute_disable_supported on p8 machine?

It turns out to be a testcase bug.  On Big endian powerpc ABI, function
ptrs are basically pointers to function descriptors.  The testcase
copies functions which results in function descriptors getting copied.
You have to apply the following patch to your test case for it to
operate as intended.  Thanks to Michael Ellermen for helping me out.
Otherwise I would be scratching my head for ever.


diff --git a/testcases/kernel/syscalls/mprotect/mprotect04.c b/testcases/kernel/syscalls/mprotect/mprotect04.c
index 1173afd..9fe9001 100644
--- a/testcases/kernel/syscalls/mprotect/mprotect04.c
+++ b/testcases/kernel/syscalls/mprotect/mprotect04.c
@@ -189,18 +189,30 @@ static void clear_cache(void *start, int len)
 #endif
 }
 
+typedef struct {
+	uintptr_t entry;
+	uintptr_t toc;
+	uintptr_t env;
+} func_descr_t;
+
+typedef void (*func_ptr_t)(void);
+
 /*
  * Copy page where &exec_func resides. Also try to copy subsequent page
  * in case exec_func is close to page boundary.
  */
-static void *get_func(void *mem)
+void *get_func(void *mem)
 {
 	uintptr_t page_sz = getpagesize();
 	uintptr_t page_mask = ~(page_sz - 1);
-	uintptr_t func_page_offset = (uintptr_t)&exec_func & (page_sz - 1);
-	void *func_copy_start = mem + func_page_offset;
-	void *page_to_copy = (void *)((uintptr_t)&exec_func & page_mask);
+	uintptr_t func_page_offset;
+	void *func_copy_start, *page_to_copy;
 	void *mem_start = mem;
+	func_descr_t *opd =  (func_descr_t *)&exec_func;
+
+	func_page_offset = (uintptr_t)opd->entry & (page_sz - 1);
+	func_copy_start = mem + func_page_offset;
+	page_to_copy = (void *)((uintptr_t)opd->entry & page_mask);
 
 	/* copy 1st page, if it's not present something is wrong */
 	if (!page_present(page_to_copy)) {
@@ -228,15 +240,17 @@ static void *get_func(void *mem)
 
 static void testfunc_protexec(void)
 {
-	void (*func)(void);
 	void *p;
+	func_ptr_t func;
+	func_descr_t opd;
 
 	sig_caught = 0;
 
 	p = SAFE_MMAP(cleanup, 0, copy_sz, PROT_READ | PROT_WRITE,
 		 MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
 
-	func = get_func(p);
+	opd.entry = (uintptr_t)get_func(p);
+	func = (func_ptr_t)&opd;
 
 	/* Change the protection to PROT_EXEC. */
 	TEST(mprotect(p, copy_sz, PROT_EXEC));


RP

Re: [bug?] Access was denied by memory protection keys in execute-only address

[Li Wang]

[-- Attachment #1: Type: text/plain, Size: 4293 bytes --]

On Thu, Mar 22, 2018 at 3:09 PM, Ram Pai <linuxram@us.ibm.com> wrote:

> On Wed, Mar 21, 2018 at 02:53:00PM +0800, Li Wang wrote:
> >    On Wed, Mar 21, 2018 at 5:58 AM, Ram Pai <[1]linuxram@us.ibm.com>
> wrote:
> >
> >      On Fri, Mar 09, 2018 at 11:43:00AM +0800, Li Wang wrote:
> >      >    On Fri, Mar 9, 2018 at 12:45 AM, Ram Pai
> >      <[1][2]linuxram@us.ibm.com> wrote:
> >      >
> >      >      On Thu, Mar 08, 2018 at 11:19:12PM +1100, Michael Ellerman
> wrote:
> >      >      > Li Wang <[2][3]liwang@redhat.com> writes:
> >      >      > > Hi,
> >      >      > >
> >      >      am wondering if the slightly different cpu behavior is
> dependent
> ..snip..
> >      on the
> >      >      version of the firmware/microcode?
> >      >
> >      >    ​I also run this reproducer on series ppc kvm machines, but
> none of
> >      them
> >      >    get the FAIL.
> >      >    If you need some more HW info, pls let me know.​
> >
> >      Hi Li,
> >
> >         Can you try the following patch and see if it solves your
> problem.
> >
> >    ​It only works on power7 lpar machine.
> >
> >    But for p8 lpar, it still get failure as that before, the thing I
> wondered
> >    is
> >    that why not disable the pkey_execute_disable_supported on p8 machine?
>
> It turns out to be a testcase bug.  On Big endian powerpc ABI, function
> ptrs are basically pointers to function descriptors.  The testcase
> copies functions which results in function descriptors getting copied.
> You have to apply the following patch to your test case for it to
> operate as intended.  Thanks to Michael Ellermen for helping me out.
> Otherwise I would be scratching my head for ever.
>

​Thanks for the explanation, I learned something new about this. :)

And the worth to say, seems the patch only works on powerpc arch,
others(x86_64, etc)
that does not works well, so a simple workaround is to isolate the code
changes
to powerpc system?


Hi Cyril & Jan,

Could any of you take a look at this patch, comments?



>
>
> diff --git a/testcases/kernel/syscalls/mprotect/mprotect04.c
> b/testcases/kernel/syscalls/mprotect/mprotect04.c
> index 1173afd..9fe9001 100644
> --- a/testcases/kernel/syscalls/mprotect/mprotect04.c
> +++ b/testcases/kernel/syscalls/mprotect/mprotect04.c
> @@ -189,18 +189,30 @@ static void clear_cache(void *start, int len)
>  #endif
>  }
>
> +typedef struct {
> +       uintptr_t entry;
> +       uintptr_t toc;
> +       uintptr_t env;
> +} func_descr_t;
> +
> +typedef void (*func_ptr_t)(void);
> +
>  /*
>   * Copy page where &exec_func resides. Also try to copy subsequent page
>   * in case exec_func is close to page boundary.
>   */
> -static void *get_func(void *mem)
> +void *get_func(void *mem)
>  {
>         uintptr_t page_sz = getpagesize();
>         uintptr_t page_mask = ~(page_sz - 1);
> -       uintptr_t func_page_offset = (uintptr_t)&exec_func & (page_sz - 1);
> -       void *func_copy_start = mem + func_page_offset;
> -       void *page_to_copy = (void *)((uintptr_t)&exec_func & page_mask);
> +       uintptr_t func_page_offset;
> +       void *func_copy_start, *page_to_copy;
>         void *mem_start = mem;
> +       func_descr_t *opd =  (func_descr_t *)&exec_func;
> +
> +       func_page_offset = (uintptr_t)opd->entry & (page_sz - 1);
> +       func_copy_start = mem + func_page_offset;
> +       page_to_copy = (void *)((uintptr_t)opd->entry & page_mask);
>
>         /* copy 1st page, if it's not present something is wrong */
>         if (!page_present(page_to_copy)) {
> @@ -228,15 +240,17 @@ static void *get_func(void *mem)
>
>  static void testfunc_protexec(void)
>  {
> -       void (*func)(void);
>         void *p;
> +       func_ptr_t func;
> +       func_descr_t opd;
>
>         sig_caught = 0;
>
>         p = SAFE_MMAP(cleanup, 0, copy_sz, PROT_READ | PROT_WRITE,
>                  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>
> -       func = get_func(p);
> +       opd.entry = (uintptr_t)get_func(p);
> +       func = (func_ptr_t)&opd;
>
>         /* Change the protection to PROT_EXEC. */
>         TEST(mprotect(p, copy_sz, PROT_EXEC));
>
>
> RP
>
>


-- 
Li Wang
liwang@redhat.com

[-- Attachment #2: Type: text/html, Size: 6124 bytes --]

Re: [bug?] Access was denied by memory protection keys in execute-only address

[Ram Pai]

On Fri, Mar 23, 2018 at 05:27:06PM +0800, Li Wang wrote:
>    On Thu, Mar 22, 2018 at 3:09 PM, Ram Pai <[1]linuxram@us.ibm.com> wrote:
> 
>      On Wed, Mar 21, 2018 at 02:53:00PM +0800, Li Wang wrote:
>      >    On Wed, Mar 21, 2018 at 5:58 AM, Ram Pai
>      <[1][2]linuxram@us.ibm.com> wrote:
>      >    that why not disable the pkey_execute_disable_supported on p8
.snip..

>      machine?
> 
>      It turns out to be a testcase bug.  On Big endian powerpc ABI, function
>      ptrs are basically pointers to function descriptors.  The testcase
>      copies functions which results in function descriptors getting copied.
>      You have to apply the following patch to your test case for it to
>      operate as intended.  Thanks to Michael Ellermen for helping me out.
>      Otherwise I would be scratching my head for ever.
> 
>    ​Thanks for the explanation, I learned something new about this. :)
> 
>    And the worth to say, seems the patch only works on powerpc arch,
>    others(x86_64, etc)
>    that does not works well, so a simple workaround is to isolate the code
>    changes
>    to powerpc system?

yes. this code has to be made applicable to powerpc Big-endian code
only.  The powerpc little-endian code remains unchanged.

RP