All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <bsingharora@gmail.com>
To: Ram Pai <linuxram@us.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Cc: benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
	khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com,
	dave.hansen@intel.com, hbabu@us.ibm.com
Subject: Re: [RFC v2 00/12] powerpc: Memory Protection Keys
Date: Tue, 20 Jun 2017 15:10:15 +1000	[thread overview]
Message-ID: <1497935415.2255.1.camel@gmail.com> (raw)
In-Reply-To: <1497671564-20030-1-git-send-email-linuxram@us.ibm.com>

On Fri, 2017-06-16 at 20:52 -0700, Ram Pai wrote:
> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.

I presume by itself you mean protection between threads?

> 
> The overall idea:
> 
>  A process allocates a   key  and associates it with
>  a  address  range  within    its   address   space.

OK, so this is per VMA?

>  The process  than  can  dynamically  set read/write 
>  permissions on  the   key   without  involving  the 
>  kernel.

This bit is not clear, how can the key be set without
involving the kernel? I presume you mean the key is set
in the PTE's and the access protection values can be
set without involving the kernel?

 Any  code that  violates   the  permissions
>  off the address space; as defined by its associated
>  key, will receive a segmentation fault.
> 
> This patch series enables the feature on PPC64.
> It is enabled on HPTE 64K-page platform.
> 
> ISA3.0 section 5.7.13 describes the detailed specifications.
> 
> 
> Testing:
> 	This patch series has passed all the protection key
> 	tests available in  the selftests directory.
> 	The tests are updated to work on both x86 and powerpc.

Balbir

  parent reply	other threads:[~2017-06-20  5:11 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-17  3:52 [RFC v2 00/12] powerpc: Memory Protection Keys Ram Pai
2017-06-17  3:52 ` [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed hpte pages Ram Pai
2017-06-20 10:20   ` Anshuman Khandual
2017-06-20 23:23     ` Ram Pai
2017-06-21  5:35       ` Anshuman Khandual
2017-06-21  6:34         ` Ram Pai
2017-06-21  6:41   ` Aneesh Kumar K.V
2017-06-21  9:30     ` Ram Pai
2017-06-22  9:07   ` Anshuman Khandual
2017-06-22 16:20     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K " Ram Pai
2017-06-20 10:51   ` Anshuman Khandual
2017-06-20 23:25     ` Ram Pai
2017-06-21  6:50   ` Aneesh Kumar K.V
2017-06-21  6:54   ` Aneesh Kumar K.V
2017-06-21 20:14     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 03/12] powerpc: Implement sys_pkey_alloc and sys_pkey_free system call Ram Pai
2017-06-19 12:18   ` Michael Ellerman
2017-06-20 22:45     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 04/12] powerpc: store and restore the pkey state across context switches Ram Pai
2017-06-17  3:52 ` [RFC v2 05/12] powerpc: Implementation for sys_mprotect_pkey() system call Ram Pai
2017-06-21  7:16   ` Aneesh Kumar K.V
2017-06-17  3:52 ` [RFC v2 06/12] powerpc: Program HPTE key protection bits Ram Pai
2017-06-20  8:21   ` Anshuman Khandual
2017-06-20 23:26     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 07/12] powerpc: Macro the mask used for checking DSI exception Ram Pai
2017-06-20  8:14   ` Anshuman Khandual
2017-06-20 23:28     ` Ram Pai
2017-06-21  7:25   ` Aneesh Kumar K.V
2017-06-21  9:17     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 08/12] powerpc: Handle exceptions caused by violation of pkey protection Ram Pai
2017-06-20  7:24   ` Anshuman Khandual
2017-06-20 23:43     ` Ram Pai
2017-06-21  3:54       ` Anshuman Khandual
2017-06-21  6:26         ` Ram Pai
2017-06-17  3:52 ` [RFC v2 09/12] powerpc: Deliver SEGV signal on pkey violation Ram Pai
2017-06-20  6:54   ` Anshuman Khandual
2017-06-20 23:56     ` Ram Pai
2017-06-21  3:18       ` Anshuman Khandual
2017-06-21  6:10         ` Ram Pai
2017-06-17  3:52 ` [RFC v2 10/12] powerpc: Read AMR only if pkey-violation caused the exception Ram Pai
2017-06-19 11:06   ` Michael Ellerman
2017-06-19 17:59     ` Ram Pai
2017-06-20  6:46       ` Anshuman Khandual
2017-06-20 23:58         ` Ram Pai
2017-06-20 23:56     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 11/12]Documentation: Documentation updates Ram Pai
2017-06-20  6:18   ` Anshuman Khandual
2017-06-21  0:04     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 12/12]selftest: Updated protection key selftest Ram Pai
2017-06-19 11:04   ` Michael Ellerman
2017-06-20  6:26   ` Anshuman Khandual
2017-06-21  0:10     ` Ram Pai
2017-06-20  5:10 ` Balbir Singh [this message]
2017-06-20  6:05   ` [RFC v2 00/12] powerpc: Memory Protection Keys Anshuman Khandual
2017-06-20  9:56   ` Benjamin Herrenschmidt

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=1497935415.2255.1.camel@gmail.com \
    --to=bsingharora@gmail.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=dave.hansen@intel.com \
    --cc=hbabu@us.ibm.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=linuxram@us.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.