From: Dave Hansen <dave.hansen@intel.com> To: ira.weiny@intel.com, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org> Cc: Fenghua Yu <fenghua.yu@intel.com>, x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>, Andrew Morton <akpm@linux-foundation.org>, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH RFC V3 5/9] x86/pks: Add PKS kernel API Date: Tue, 13 Oct 2020 11:43:57 -0700 [thread overview] Message-ID: <29e9b8f1-35d6-d1d4-661d-a36fd296b593@intel.com> (raw) In-Reply-To: <20201009194258.3207172-6-ira.weiny@intel.com> > +static inline void pks_update_protection(int pkey, unsigned long protection) > +{ > + current->thread.saved_pkrs = update_pkey_val(current->thread.saved_pkrs, > + pkey, protection); > + preempt_disable(); > + write_pkrs(current->thread.saved_pkrs); > + preempt_enable(); > +} Why does this need preempt count manipulation in addition to the get/put_cpu_var() inside of write_pkrs()? > +/** > + * PKS access control functions > + * > + * Change the access of the domain specified by the pkey. These are global > + * updates. They only affects the current running thread. It is undefined and > + * a bug for users to call this without having allocated a pkey and using it as > + * pkey here. > + * > + * pks_mknoaccess() > + * Disable all access to the domain > + * pks_mkread() > + * Make the domain Read only > + * pks_mkrdwr() > + * Make the domain Read/Write > + * > + * @pkey the pkey for which the access should change. > + * > + */ > +void pks_mknoaccess(int pkey) > +{ > + pks_update_protection(pkey, PKEY_DISABLE_ACCESS); > +} > +EXPORT_SYMBOL_GPL(pks_mknoaccess); These are named like PTE manipulation functions, which is kinda weird. What's wrong with: pks_disable_access(pkey) ? > +void pks_mkread(int pkey) > +{ > + pks_update_protection(pkey, PKEY_DISABLE_WRITE); > +} > +EXPORT_SYMBOL_GPL(pks_mkread); I really don't like this name. It doesn't make readable, or even read-only, *especially* if it was already access-disabled. > +static const char pks_key_user0[] = "kernel"; > + > +/* Store names of allocated keys for debug. Key 0 is reserved for the kernel. */ > +static const char *pks_key_users[PKS_NUM_KEYS] = { > + pks_key_user0 > +}; > + > +/* > + * Each key is represented by a bit. Bit 0 is set for key 0 and reserved for > + * its use. We use ulong for the bit operations but only 16 bits are used. > + */ > +static unsigned long pks_key_allocation_map = 1 << PKS_KERN_DEFAULT_KEY; > + > +/* > + * pks_key_alloc - Allocate a PKS key > + * > + * @pkey_user: String stored for debugging of key exhaustion. The caller is > + * responsible to maintain this memory until pks_key_free(). > + */ > +int pks_key_alloc(const char * const pkey_user) > +{ > + int nr; > + > + if (!cpu_feature_enabled(X86_FEATURE_PKS)) > + return -EINVAL; I'm not sure I like -EINVAL for this. I thought we returned -ENOSPC for this case for user pkeys. > + while (1) { > + nr = find_first_zero_bit(&pks_key_allocation_map, PKS_NUM_KEYS); > + if (nr >= PKS_NUM_KEYS) { > + pr_info("Cannot allocate supervisor key for %s.\n", > + pkey_user); > + return -ENOSPC; > + } > + if (!test_and_set_bit_lock(nr, &pks_key_allocation_map)) > + break; > + } > + > + /* for debugging key exhaustion */ > + pks_key_users[nr] = pkey_user; > + > + return nr; > +} > +EXPORT_SYMBOL_GPL(pks_key_alloc); > + > +/* > + * pks_key_free - Free a previously allocate PKS key > + * > + * @pkey: Key to be free'ed > + */ > +void pks_key_free(int pkey) > +{ > + if (!cpu_feature_enabled(X86_FEATURE_PKS)) > + return; > + > + if (pkey >= PKS_NUM_KEYS || pkey <= PKS_KERN_DEFAULT_KEY) > + return; This seems worthy of a WARN_ON_ONCE() at least. It's essentially corrupt data coming into a kernel API. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@intel.com> To: ira.weiny@intel.com, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org> Cc: Fenghua Yu <fenghua.yu@intel.com>, x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>, Dan Williams <dan.j.williams@intel.com>, Andrew Morton <akpm@linux-foundation.org>, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH RFC V3 5/9] x86/pks: Add PKS kernel API Date: Tue, 13 Oct 2020 11:43:57 -0700 [thread overview] Message-ID: <29e9b8f1-35d6-d1d4-661d-a36fd296b593@intel.com> (raw) In-Reply-To: <20201009194258.3207172-6-ira.weiny@intel.com> > +static inline void pks_update_protection(int pkey, unsigned long protection) > +{ > + current->thread.saved_pkrs = update_pkey_val(current->thread.saved_pkrs, > + pkey, protection); > + preempt_disable(); > + write_pkrs(current->thread.saved_pkrs); > + preempt_enable(); > +} Why does this need preempt count manipulation in addition to the get/put_cpu_var() inside of write_pkrs()? > +/** > + * PKS access control functions > + * > + * Change the access of the domain specified by the pkey. These are global > + * updates. They only affects the current running thread. It is undefined and > + * a bug for users to call this without having allocated a pkey and using it as > + * pkey here. > + * > + * pks_mknoaccess() > + * Disable all access to the domain > + * pks_mkread() > + * Make the domain Read only > + * pks_mkrdwr() > + * Make the domain Read/Write > + * > + * @pkey the pkey for which the access should change. > + * > + */ > +void pks_mknoaccess(int pkey) > +{ > + pks_update_protection(pkey, PKEY_DISABLE_ACCESS); > +} > +EXPORT_SYMBOL_GPL(pks_mknoaccess); These are named like PTE manipulation functions, which is kinda weird. What's wrong with: pks_disable_access(pkey) ? > +void pks_mkread(int pkey) > +{ > + pks_update_protection(pkey, PKEY_DISABLE_WRITE); > +} > +EXPORT_SYMBOL_GPL(pks_mkread); I really don't like this name. It doesn't make readable, or even read-only, *especially* if it was already access-disabled. > +static const char pks_key_user0[] = "kernel"; > + > +/* Store names of allocated keys for debug. Key 0 is reserved for the kernel. */ > +static const char *pks_key_users[PKS_NUM_KEYS] = { > + pks_key_user0 > +}; > + > +/* > + * Each key is represented by a bit. Bit 0 is set for key 0 and reserved for > + * its use. We use ulong for the bit operations but only 16 bits are used. > + */ > +static unsigned long pks_key_allocation_map = 1 << PKS_KERN_DEFAULT_KEY; > + > +/* > + * pks_key_alloc - Allocate a PKS key > + * > + * @pkey_user: String stored for debugging of key exhaustion. The caller is > + * responsible to maintain this memory until pks_key_free(). > + */ > +int pks_key_alloc(const char * const pkey_user) > +{ > + int nr; > + > + if (!cpu_feature_enabled(X86_FEATURE_PKS)) > + return -EINVAL; I'm not sure I like -EINVAL for this. I thought we returned -ENOSPC for this case for user pkeys. > + while (1) { > + nr = find_first_zero_bit(&pks_key_allocation_map, PKS_NUM_KEYS); > + if (nr >= PKS_NUM_KEYS) { > + pr_info("Cannot allocate supervisor key for %s.\n", > + pkey_user); > + return -ENOSPC; > + } > + if (!test_and_set_bit_lock(nr, &pks_key_allocation_map)) > + break; > + } > + > + /* for debugging key exhaustion */ > + pks_key_users[nr] = pkey_user; > + > + return nr; > +} > +EXPORT_SYMBOL_GPL(pks_key_alloc); > + > +/* > + * pks_key_free - Free a previously allocate PKS key > + * > + * @pkey: Key to be free'ed > + */ > +void pks_key_free(int pkey) > +{ > + if (!cpu_feature_enabled(X86_FEATURE_PKS)) > + return; > + > + if (pkey >= PKS_NUM_KEYS || pkey <= PKS_KERN_DEFAULT_KEY) > + return; This seems worthy of a WARN_ON_ONCE() at least. It's essentially corrupt data coming into a kernel API.
next prev parent reply other threads:[~2020-10-13 18:44 UTC|newest] Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-09 19:42 [PATCH RFC V3 0/9] PKS: Add Protection Keys Supervisor (PKS) support RFC v3 ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-09 19:42 ` [PATCH RFC V3 1/9] x86/pkeys: Create pkeys_common.h ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-13 17:46 ` Dave Hansen 2020-10-13 17:46 ` Dave Hansen 2020-10-13 19:44 ` Ira Weiny 2020-10-13 19:44 ` Ira Weiny 2020-10-09 19:42 ` [PATCH RFC V3 2/9] x86/fpu: Refactor arch_set_user_pkey_access() for PKS support ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-13 17:50 ` Dave Hansen 2020-10-13 17:50 ` Dave Hansen 2020-10-13 23:56 ` Ira Weiny 2020-10-13 23:56 ` Ira Weiny 2020-10-16 10:57 ` Peter Zijlstra 2020-10-16 10:57 ` Peter Zijlstra 2020-10-17 3:32 ` Ira Weiny 2020-10-17 3:32 ` Ira Weiny 2020-10-19 9:35 ` Peter Zijlstra 2020-10-19 9:35 ` Peter Zijlstra 2020-10-09 19:42 ` [PATCH RFC V3 3/9] x86/pks: Enable Protection Keys Supervisor (PKS) ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-13 18:23 ` Dave Hansen 2020-10-13 18:23 ` Dave Hansen 2020-10-14 2:08 ` Ira Weiny 2020-10-14 2:08 ` Ira Weiny 2020-10-09 19:42 ` [PATCH RFC V3 4/9] x86/pks: Preserve the PKRS MSR on context switch ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-13 18:31 ` Dave Hansen 2020-10-13 18:31 ` Dave Hansen 2020-10-14 22:36 ` Ira Weiny 2020-10-14 22:36 ` Ira Weiny 2020-10-16 11:12 ` Peter Zijlstra 2020-10-16 11:12 ` Peter Zijlstra 2020-10-17 5:14 ` Ira Weiny 2020-10-17 5:14 ` Ira Weiny 2020-10-19 9:37 ` Peter Zijlstra 2020-10-19 9:37 ` Peter Zijlstra 2020-10-19 18:48 ` Ira Weiny 2020-10-19 18:48 ` Ira Weiny 2020-10-16 11:06 ` Peter Zijlstra 2020-10-16 11:06 ` Peter Zijlstra 2020-10-17 5:37 ` Ira Weiny 2020-10-17 5:37 ` Ira Weiny 2020-10-09 19:42 ` [PATCH RFC V3 5/9] x86/pks: Add PKS kernel API ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-13 18:43 ` Dave Hansen [this message] 2020-10-13 18:43 ` Dave Hansen 2020-10-15 1:08 ` Ira Weiny 2020-10-15 1:08 ` Ira Weiny 2020-10-16 11:07 ` Peter Zijlstra 2020-10-16 11:07 ` Peter Zijlstra 2020-10-17 5:42 ` Ira Weiny 2020-10-17 5:42 ` Ira Weiny 2020-10-09 19:42 ` [PATCH RFC V3 6/9] x86/entry: Pass irqentry_state_t by reference ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-16 11:45 ` Peter Zijlstra 2020-10-16 11:45 ` Peter Zijlstra 2020-10-16 12:55 ` Thomas Gleixner 2020-10-16 12:55 ` Thomas Gleixner 2020-10-19 5:37 ` Ira Weiny 2020-10-19 5:37 ` Ira Weiny 2020-10-19 9:32 ` Thomas Gleixner 2020-10-19 9:32 ` Thomas Gleixner 2020-10-19 20:26 ` Ira Weiny 2020-10-19 20:26 ` Ira Weiny 2020-10-19 21:12 ` Thomas Gleixner 2020-10-19 21:12 ` Thomas Gleixner 2020-10-20 14:10 ` Ira Weiny 2020-10-20 14:10 ` Ira Weiny 2020-10-09 19:42 ` [PATCH RFC V3 7/9] x86/entry: Preserve PKRS MSR across exceptions ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-13 18:52 ` Dave Hansen 2020-10-13 18:52 ` Dave Hansen 2020-10-15 3:46 ` Ira Weiny 2020-10-15 3:46 ` Ira Weiny 2020-10-15 4:06 ` Dave Hansen 2020-10-15 4:06 ` Dave Hansen 2020-10-15 4:18 ` Ira Weiny 2020-10-15 4:18 ` Ira Weiny 2020-10-09 19:42 ` [PATCH RFC V3 8/9] x86/fault: Report the PKRS state on fault ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-13 18:56 ` Dave Hansen 2020-10-13 18:56 ` Dave Hansen 2020-10-15 4:13 ` Ira Weiny 2020-10-15 4:13 ` Ira Weiny 2020-10-09 19:42 ` [PATCH RFC V3 9/9] x86/pks: Add PKS test code ira.weiny 2020-10-09 19:42 ` ira.weiny 2020-10-13 19:02 ` Dave Hansen 2020-10-13 19:02 ` Dave Hansen 2020-10-15 4:46 ` Ira Weiny 2020-10-15 4:46 ` Ira Weiny 2020-10-09 20:18 ` [PATCH RFC V3 0/9] PKS: Add Protection Keys Supervisor (PKS) support RFC v3 Ira Weiny 2020-10-09 20:18 ` Ira Weiny
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=29e9b8f1-35d6-d1d4-661d-a36fd296b593@intel.com \ --to=dave.hansen@intel.com \ --cc=akpm@linux-foundation.org \ --cc=bp@alien8.de \ --cc=dave.hansen@linux.intel.com \ --cc=fenghua.yu@intel.com \ --cc=ira.weiny@intel.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=luto@kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.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: linkBe 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.