1. 24 Jul, 2018 6 commits
    • Ram Pai's avatar
      powerpc/pkeys: Preallocate execute-only key · a4fcc877
      Ram Pai authored
      execute-only key is allocated dynamically. This is a problem. When a
      thread implicitly creates an execute-only key, and resets the UAMOR
      for that key, the UAMOR value does not percolate to all the other
      threads. Any other thread may ignorantly change the permissions on the
      key. This can cause the key to be not execute-only for that thread.
      
      Preallocate the execute-only key and ensure that no thread can change
      the permission of the key, by resetting the corresponding bit in
      UAMOR.
      
      Fixes: 5586cf61 ("powerpc: introduce execute-only pkey")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: default avatarRam Pai <linuxram@us.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      a4fcc877
    • Ram Pai's avatar
      powerpc/pkeys: Fix calculation of total pkeys. · fe6a2804
      Ram Pai authored
      Total number of pkeys calculation is off by 1. Fix it.
      
      Fixes: 4fb158f6 ("powerpc: track allocation status of all pkeys")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: default avatarRam Pai <linuxram@us.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      fe6a2804
    • Ram Pai's avatar
      powerpc/pkeys: Save the pkey registers before fork · c76662e8
      Ram Pai authored
      When a thread forks the contents of AMR, IAMR, UAMOR registers in the
      newly forked thread are not inherited.
      
      Save the registers before forking, for content of those
      registers to be automatically copied into the new thread.
      
      Fixes: cf43d3b2 ("powerpc: Enable pkey subsystem")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: default avatarRam Pai <linuxram@us.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      c76662e8
    • Ram Pai's avatar
      powerpc/pkeys: key allocation/deallocation must not change pkey registers · 4a4a5e5d
      Ram Pai authored
      Key allocation and deallocation has the side effect of programming the
      UAMOR/AMR/IAMR registers. This is wrong, since its the responsibility of
      the application and not that of the kernel, to modify the permission on
      the key.
      
      Do not modify the pkey registers at key allocation/deallocation.
      
      This patch also fixes a bug where a sys_pkey_free() resets the UAMOR
      bits of the key, thus making its permissions unmodifiable from user
      space. Later if the same key gets reallocated from a different thread
      this thread will no longer be able to change the permissions on the key.
      
      Fixes: cf43d3b2 ("powerpc: Enable pkey subsystem")
      Cc: stable@vger.kernel.org # v4.16+
      Reviewed-by: default avatarThiago Jung Bauermann <bauerman@linux.ibm.com>
      Signed-off-by: default avatarRam Pai <linuxram@us.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      4a4a5e5d
    • Ram Pai's avatar
      powerpc/pkeys: Deny read/write/execute by default · de113256
      Ram Pai authored
      Deny all permissions on all keys, with some exceptions. pkey-0 must
      allow all permissions, or else everything comes to a screaching halt.
      Execute-only key must allow execute permission.
      
      Fixes: cf43d3b2 ("powerpc: Enable pkey subsystem")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: default avatarRam Pai <linuxram@us.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      de113256
    • Ram Pai's avatar
      powerpc/pkeys: Give all threads control of their key permissions · a57a04c7
      Ram Pai authored
      Currently in a multithreaded application, a key allocated by one
      thread is not usable by other threads. By "not usable" we mean that
      other threads are unable to change the access permissions for that
      key for themselves.
      
      When a new key is allocated in one thread, the corresponding UAMOR
      bits for that thread get enabled, however the UAMOR bits for that key
      for all other threads remain disabled.
      
      Other threads have no way to set permissions on the key, and the
      current default permissions are that read/write is enabled for all
      keys, which means the key has no effect for other threads. Although
      that may be the desired behaviour in some circumstances, having all
      threads able to control their permissions for the key is more
      flexible.
      
      The current behaviour also differs from the x86 behaviour, which is
      problematic for users.
      
      To fix this, enable the UAMOR bits for all keys, at process
      creation (in start_thread(), ie exec time). Since the contents of
      UAMOR are inherited at fork, all threads are capable of modifying the
      permissions on any key.
      
      This is technically an ABI break on powerpc, but pkey support is fairly
      new on powerpc and not widely used, and this brings us into
      line with x86.
      
      Fixes: cf43d3b2 ("powerpc: Enable pkey subsystem")
      Cc: stable@vger.kernel.org # v4.16+
      Tested-by: default avatarFlorian Weimer <fweimer@redhat.com>
      Signed-off-by: default avatarRam Pai <linuxram@us.ibm.com>
      [mpe: Reword some of the changelog]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      a57a04c7
  2. 20 Jul, 2018 5 commits
  3. 19 Jul, 2018 8 commits
  4. 16 Jul, 2018 7 commits
  5. 12 Jul, 2018 3 commits
  6. 10 Jul, 2018 3 commits
  7. 09 Jul, 2018 1 commit
  8. 04 Jul, 2018 4 commits
  9. 03 Jul, 2018 1 commit
  10. 02 Jul, 2018 2 commits