From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data Date: Mon, 29 Oct 2018 09:37:32 -0700 Message-ID: <7d93080b-68bd-7563-bd3b-e7ee1545e367@intel.com> References: <20181029112343.27454-1-msammler@mpi-sws.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Kees Cook , Michael Sammler Cc: Will Drewry , Linux API , Dave Hansen , Ram Pai , Andy Lutomirski , PowerPC List-Id: linux-api@vger.kernel.org On 10/29/18 9:25 AM, Kees Cook wrote: > On Mon, Oct 29, 2018 at 4:23 AM, Michael Sammler wrote: >> Add the current value of an architecture specific protection keys >> register (currently PKRU on x86) to data available for seccomp-bpf >> programs to work on. This allows filters based on the currently >> enabled protection keys. How does the current "assignment" of protection keys to the various uses get communicated to the filter? I'm not sure this is a great use for PKRU. I *think* the basic problem is that you want to communicate some rights information down into a filter, and you want to communicate it with PKRU. While it's handy to have an extra register that nobody (generally) mucks with, I'm not quite convinced that we want to repurpose it this way. Also, I'm not sure the kernel provides the PKRU guarantees you want at the moment. Our implementation *probably* works, but it's mostly by accident.