All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Michal Hocko <mhocko@kernel.org>,
	linux-mm@kvack.org, Ingo Molnar <mingo@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linuxppc-dev@lists.ozlabs.org,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [RFC v7 26/25] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface
Date: Fri, 18 Aug 2017 20:19:01 -0300	[thread overview]
Message-ID: <87fucoo462.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170818002512.GE5427@ram.oc3035372033.ibm.com>


Ram Pai <linuxram@us.ibm.com> writes:

> On Fri, Aug 11, 2017 at 02:34:43PM -0300, Thiago Jung Bauermann wrote:
>> Expose useful information for programs using memory protection keys.
>> Provide implementation for powerpc and x86.
>> 
>> On a powerpc system with pkeys support, here is what is shown:
>> 
>> $ head /sys/kernel/mm/protection_keys/*
>> ==> /sys/kernel/mm/protection_keys/disable_execute_supported <==
>> true
>
> We should not just call out disable_execute_supported.
> disable_access_supported and disable_write_supported should also 
> be called out.

Ok, will do in the next version.

>> ==> /sys/kernel/mm/protection_keys/total_keys <==
>> 32
>> 
>
>> ==> /sys/kernel/mm/protection_keys/usable_keys <==
>> 30
>
> This is little nebulous.  It depends on how we define
> usable as.  Is it the number of keys that are available
> to the app?  If that is the case that value is dynamic.
> Sometime the OS steals one key for execute-only key.
> And anything that is dynamic can be inherently racy.
> So I think we should define 'usable' as guaranteed number
> of keys available to the app

Yes, that is how I defined it: the difference between the number of keys
provided by the platform and the keys reserved by the OS. I do need to
spell it out somewhere inside Documentation/ though.

> and display a value that is one less than what is available.
>
> in the above example the value should be 29.

Good point, I didn't account for the execute-only key. I will make that
change in the next version.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

WARNING: multiple messages have this Message-ID (diff)
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Michal Hocko <mhocko@kernel.org>,
	linux-mm@kvack.org, Ingo Molnar <mingo@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linuxppc-dev@lists.ozlabs.org,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [RFC v7 26/25] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface
Date: Fri, 18 Aug 2017 20:19:01 -0300	[thread overview]
Message-ID: <87fucoo462.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170818002512.GE5427@ram.oc3035372033.ibm.com>


Ram Pai <linuxram@us.ibm.com> writes:

> On Fri, Aug 11, 2017 at 02:34:43PM -0300, Thiago Jung Bauermann wrote:
>> Expose useful information for programs using memory protection keys.
>> Provide implementation for powerpc and x86.
>> 
>> On a powerpc system with pkeys support, here is what is shown:
>> 
>> $ head /sys/kernel/mm/protection_keys/*
>> ==> /sys/kernel/mm/protection_keys/disable_execute_supported <==
>> true
>
> We should not just call out disable_execute_supported.
> disable_access_supported and disable_write_supported should also 
> be called out.

Ok, will do in the next version.

>> ==> /sys/kernel/mm/protection_keys/total_keys <==
>> 32
>> 
>
>> ==> /sys/kernel/mm/protection_keys/usable_keys <==
>> 30
>
> This is little nebulous.  It depends on how we define
> usable as.  Is it the number of keys that are available
> to the app?  If that is the case that value is dynamic.
> Sometime the OS steals one key for execute-only key.
> And anything that is dynamic can be inherently racy.
> So I think we should define 'usable' as guaranteed number
> of keys available to the app

Yes, that is how I defined it: the difference between the number of keys
provided by the platform and the keys reserved by the OS. I do need to
spell it out somewhere inside Documentation/ though.

> and display a value that is one less than what is available.
>
> in the above example the value should be 29.

Good point, I didn't account for the execute-only key. I will make that
change in the next version.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-08-18 23:19 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-31  0:12 [RFC v7 00/25] powerpc: Memory Protection Keys Ram Pai
2017-07-31  0:12 ` [RFC v7 01/25] powerpc: define an additional vma bit for protection keys Ram Pai
2017-07-31  0:12 ` [RFC v7 02/25] powerpc: track allocation status of all pkeys Ram Pai
2017-08-10 20:25   ` Thiago Jung Bauermann
2017-08-11  5:39     ` Michael Ellerman
2017-08-17 16:00       ` Ram Pai
2017-08-17 15:48     ` Ram Pai
2017-08-17 20:40       ` Thiago Jung Bauermann
2017-10-18  2:42   ` Balbir Singh
2017-10-18  3:40     ` Ram Pai
2017-10-18 16:08   ` Laurent Dufour
2017-10-18 22:04     ` Ram Pai
2017-07-31  0:12 ` [RFC v7 03/25] powerpc: helper function to read, write AMR, IAMR, UAMOR registers Ram Pai
2017-07-31  0:12 ` [RFC v7 04/25] powerpc: helper functions to initialize AMR, IAMR and " Ram Pai
2017-07-31  0:12 ` [RFC v7 05/25] powerpc: cleaup AMR, iAMR when a key is allocated or freed Ram Pai
2017-07-31  0:12 ` [RFC v7 06/25] powerpc: implementation for arch_set_user_pkey_access() Ram Pai
2017-07-31  0:12 ` [RFC v7 07/25] powerpc: sys_pkey_alloc() and sys_pkey_free() system calls Ram Pai
2017-07-31  0:12 ` [RFC v7 08/25] powerpc: ability to create execute-disabled pkeys Ram Pai
2017-07-31  0:12 ` [RFC v7 09/25] powerpc: store and restore the pkey state across context switches Ram Pai
2017-08-10 20:46   ` Thiago Jung Bauermann
2017-08-11  6:34     ` Michael Ellerman
2017-08-17 16:41       ` Ram Pai
2017-07-31  0:12 ` [RFC v7 10/25] powerpc: introduce execute-only pkey Ram Pai
2017-07-31  0:12 ` [RFC v7 11/25] powerpc: ability to associate pkey to a vma Ram Pai
2017-07-31  0:12 ` [RFC v7 12/25] powerpc: implementation for arch_override_mprotect_pkey() Ram Pai
2017-10-18 15:58   ` Laurent Dufour
2017-10-18 21:37     ` Ram Pai
2017-07-31  0:12 ` [RFC v7 13/25] powerpc: map vma key-protection bits to pte key bits Ram Pai
2017-07-31  0:12 ` [RFC v7 14/25] powerpc: sys_pkey_mprotect() system call Ram Pai
2017-07-31  0:12 ` [RFC v7 15/25] powerpc: Program HPTE key protection bits Ram Pai
2017-10-18 16:15   ` Laurent Dufour
2017-10-18 22:12     ` Ram Pai
2017-10-19  5:12       ` Michael Ellerman
2017-07-31  0:12 ` [RFC v7 16/25] powerpc: helper to validate key-access permissions of a pte Ram Pai
2017-10-18 16:08   ` Laurent Dufour
2017-10-18 21:56     ` Ram Pai
2017-10-19  5:13       ` Michael Ellerman
2017-07-31  0:12 ` [RFC v7 17/25] powerpc: check key protection for user page access Ram Pai
2017-07-31  0:12 ` [RFC v7 18/25] powerpc: Macro the mask used for checking DSI exception Ram Pai
2017-07-31  0:12 ` [RFC v7 19/25] powerpc: implementation for arch_vma_access_permitted() Ram Pai
2017-07-31  0:12 ` [RFC v7 20/25] powerpc: Handle exceptions caused by pkey violation Ram Pai
2017-07-31  0:12 ` [RFC v7 21/25] powerpc: capture AMR register content on " Ram Pai
2017-07-31  0:12 ` [RFC v7 22/25] powerpc: introduce get_pte_pkey() helper Ram Pai
2017-07-31  0:12 ` [RFC v7 23/25] powerpc: capture the violated protection key on fault Ram Pai
2017-07-31  0:12 ` [RFC v7 24/25] powerpc: Deliver SEGV signal on pkey violation Ram Pai
2017-08-10 21:00   ` Thiago Jung Bauermann
2017-08-11 10:26     ` Michael Ellerman
2017-08-17 17:14       ` Ram Pai
2017-08-18  4:48         ` Michael Ellerman
2017-08-18 17:04           ` Ram Pai
2017-08-18 21:54             ` Benjamin Herrenschmidt
2017-08-18 22:36               ` Ram Pai
2017-10-18  2:25                 ` Balbir Singh
2017-10-18  3:01                   ` Ram Pai
2017-08-18 22:49             ` Ram Pai
2017-08-19  8:23               ` Benjamin Herrenschmidt
2017-07-31  0:12 ` [RFC v7 25/25] powerpc: Enable pkey subsystem Ram Pai
2017-08-10 21:27   ` Thiago Jung Bauermann
2017-08-17 17:40     ` Ram Pai
2017-08-17 20:30       ` Thiago Jung Bauermann
2017-08-17 23:48         ` Ram Pai
2017-08-18  5:07           ` Michael Ellerman
2017-08-18 15:26             ` Thiago Jung Bauermann
2017-08-18 16:32               ` Ram Pai
2017-08-11 17:34 ` [RFC v7 26/25] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface Thiago Jung Bauermann
2017-08-11 17:34   ` Thiago Jung Bauermann
2017-08-18  0:25   ` Ram Pai
2017-08-18  0:25     ` Ram Pai
2017-08-18 23:19     ` Thiago Jung Bauermann [this message]
2017-08-18 23:19       ` Thiago Jung Bauermann

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=87fucoo462.fsf@linux.vnet.ibm.com \
    --to=bauerman@linux.vnet.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=linuxram@us.ibm.com \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.