linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-mm <linux-mm@kvack.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Andy Lutomirski <luto@amacapital.net>
Subject: Re: pkeys on POWER: Access rights not reset on execve
Date: Fri, 18 May 2018 18:19:47 -0700	[thread overview]
Message-ID: <20180519011947.GJ5479@ram.oc3035372033.ibm.com> (raw)
In-Reply-To: <53828769-23c4-b2e3-cf59-239936819c3e@redhat.com>

On Fri, May 18, 2018 at 04:27:14PM +0200, Florian Weimer wrote:
> This test program:
> 
> #include <errno.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <sys/syscall.h>
> #include <err.h>
> 
> /* Return the value of the AMR register.  */
> static inline unsigned long int
> pkey_read (void)
> {
>   unsigned long int result;
>   __asm__ volatile ("mfspr %0, 13" : "=r" (result));
>   return result;
> }
> 
> /* Overwrite the AMR register with VALUE.  */
> static inline void
> pkey_write (unsigned long int value)
> {
>   __asm__ volatile ("mtspr 13, %0" : : "r" (value));
> }
> 
> int
> main (int argc, char **argv)
> {
>   printf ("AMR (PID %d): 0x%016lx\n", (int) getpid (), pkey_read());
>   if (argc > 1)
>     {
>       int key = syscall (__NR_pkey_alloc, 0, 0);
>       if (key < 0)
>         err (1, "pkey_alloc");
>       printf ("Allocated key (PID %d): %d\n", (int) getpid (), key);
>       return 0;
>     }
> 
>   pid_t pid = fork ();
>   if (pid == 0)
>     {
>       execl ("/proc/self/exe", argv[0], "subprocess", NULL);
>       _exit (1);
>     }
>   if (pid < 0)
>     err (1, "fork");
>   int status;
>   if (waitpid (pid, &status, 0) < 0)
>     err (1, "waitpid");
> 
>   int key = syscall (__NR_pkey_alloc, 0, 0);
>   if (key < 0)
>     err (1, "pkey_alloc");
>   printf ("Allocated key (PID %d): %d\n", (int) getpid (), key);
> 
>   unsigned long int amr = -1;
>   printf ("Setting AMR: 0x%016lx\n", amr);
>   pkey_write (amr);
>   printf ("New AMR value (PID %d, before execl): 0x%016lx\n",
>           (int) getpid (), pkey_read());
>   execl ("/proc/self/exe", argv[0], "subprocess", NULL);
>   err (1, "exec");
>   return 1;
> }
> 
> shows that the AMR register value is not reset on execve:
> 
> AMR (PID 112291): 0x0000000000000000
> AMR (PID 112292): 0x0000000000000000
> Allocated key (PID 112292): 2
> Allocated key (PID 112291): 2
> Setting AMR: 0xffffffffffffffff
> New AMR value (PID 112291, before execl): 0x0c00000000000000
> AMR (PID 112291): 0x0c00000000000000
> Allocated key (PID 112291): 2
> 
> I think this is a real bug and needs to be fixed even if the
> defaults are kept as-is (see the other thread).

The issue you may be talking about here is that  --

"when you set the AMR register to 0xffffffffffffffff, it 
just sets it to 0x0c00000000000000."

To me it looks like, exec/fork are not related to the issue.
Or are they also somehow connected to the issue?


The reason the AMR register does not get set to 0xffffffffffffffff,
is because none of those keys; except key 2, are active. So it ignores
all other bits and just sets the bits corresponding to key 2.

However the fundamental issue is still the same, as mentioned in the
other thread.

"Should the permissions on a key be allowed to be changed, if the key
is not allocated in the first place?".

my answer is NO. Lets debate :)
RP

  reply	other threads:[~2018-05-19  1:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18 14:27 Florian Weimer
2018-05-19  1:19 ` Ram Pai [this message]
2018-05-19  1:50   ` Andy Lutomirski
2018-05-19  5:26     ` Florian Weimer
2018-05-19 20:27     ` Ram Pai
2018-05-19 23:47       ` Andy Lutomirski
2018-05-20  6:04         ` Ram Pai
2018-05-20  6:06           ` Andy Lutomirski
2018-05-20 19:11             ` Ram Pai
2018-05-21 11:29               ` Florian Weimer
2018-06-03 20:18                 ` Ram Pai
2018-06-04 10:12                   ` Florian Weimer
2018-06-04 14:01                     ` Ram Pai
2018-06-04 17:57                       ` Florian Weimer
2018-06-04 19:02                         ` Ram Pai
2018-06-04 21:00                           ` Florian Weimer
2018-06-08  2:34                             ` Ram Pai
2018-06-08  5:53                               ` Florian Weimer
2018-06-08 10:15                                 ` Michal Suchánek
2018-06-08 10:44                                   ` Florian Weimer
2018-06-08 12:54                                     ` Michal Suchánek
2018-06-08 12:57                                       ` Florian Weimer
2018-06-08 13:49                                         ` Michal Suchánek
2018-06-08 13:51                                           ` Florian Weimer
2018-06-08 14:17                                             ` Michal Suchánek
2018-06-11 17:23                                 ` Ram Pai
2018-06-11 17:29                                   ` Florian Weimer
2018-06-11 20:08                                     ` Ram Pai
2018-06-12 12:17                                       ` Florian Weimer
2018-05-19  5:12   ` Florian Weimer
2018-05-19 11:11   ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180519011947.GJ5479@ram.oc3035372033.ibm.com \
    --to=linuxram@us.ibm.com \
    --cc=dave.hansen@intel.com \
    --cc=fweimer@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@amacapital.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox