From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752810AbbJBRul (ORCPT ); Fri, 2 Oct 2015 13:50:41 -0400 Received: from www.sr71.net ([198.145.64.142]:53532 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751979AbbJBRuk (ORCPT ); Fri, 2 Oct 2015 13:50:40 -0400 Subject: Re: [PATCH 26/26] x86, pkeys: Documentation To: Ingo Molnar , Andy Lutomirski References: <20150916174903.E112E464@viggo.jf.intel.com> <20150916174913.AF5FEA6D@viggo.jf.intel.com> <20150920085554.GA21906@gmail.com> <55FF88BA.6080006@sr71.net> <20150924094956.GA30349@gmail.com> <56044A88.7030203@sr71.net> <20151001111718.GA25333@gmail.com> <20151002062340.GB30051@gmail.com> Cc: Kees Cook , "x86@kernel.org" , LKML , Linux-MM , Linus Torvalds , Andrew Morton , Peter Zijlstra , Andy Lutomirski , Borislav Petkov From: Dave Hansen Message-ID: <560EC3EC.2080803@sr71.net> Date: Fri, 2 Oct 2015 10:50:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151002062340.GB30051@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/01/2015 11:23 PM, Ingo Molnar wrote: >> > Also, how do we do mprotect_pkey and say "don't change the key"? > So if we start managing keys as a resource (i.e. alloc/free up to 16 of them), and > provide APIs for user-space to do all that, then user-space is not supposed to > touch keys it has not allocated for itself - just like it's not supposed to write > to fds it has not opened. I like that. It gives us at least a "soft" indicator to userspace about what keys it should or shouldn't be using. > Such an allocation method can still 'mess up', and if the kernel allocates a key > for its purposes it should not assume that user-space cannot change it, but at > least for non-buggy code there's no interaction and it would work out fine. Yeah. It also provides a clean interface so that future hardware could enforce enforce kernel "ownership" of a key which could protect against even buggy code. So, we add a pair of syscalls, unsigned long sys_alloc_pkey(unsigned long flags??) unsigned long sys_free_pkey(unsigned long pkey) keep the metadata in the mm, and then make sure that userspace allocated it before it is allowed to do an mprotect_pkey() with it. mprotect_pkey(add, flags, pkey) { if (!(mm->pkeys_allocated & (1 << pkey)) return -EINVAL; } That should be pretty easy to implement. The only real overhead is the 16 bits we need to keep in the mm somewhere.