From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933577AbbIDUeM (ORCPT ); Fri, 4 Sep 2015 16:34:12 -0400 Received: from albireo.enyo.de ([46.237.207.196]:60386 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932806AbbIDUeL (ORCPT ); Fri, 4 Sep 2015 16:34:11 -0400 X-Greylist: delayed 1215 seconds by postgrey-1.27 at vger.kernel.org; Fri, 04 Sep 2015 16:34:11 EDT From: Florian Weimer To: Dave Hansen Cc: One Thousand Gnomes , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits to syscalls References: <20150507174132.34AF8FAF@viggo.jf.intel.com> <20150507174135.FD8A0FA9@viggo.jf.intel.com> <20150507201151.5658faa1@lxorguk.ukuu.org.uk> <554BBABB.9070207@sr71.net> <87twraeydh.fsf@mid.deneb.enyo.de> <55E9FC96.7000400@sr71.net> Date: Fri, 04 Sep 2015 22:34:06 +0200 In-Reply-To: <55E9FC96.7000400@sr71.net> (Dave Hansen's message of "Fri, 4 Sep 2015 13:18:30 -0700") Message-ID: <87pp1xgc01.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Dave Hansen: > On 09/04/2015 01:13 PM, Florian Weimer wrote: > ... >>>>> >>> #define PROT_WRITE 0x2 /* page can be written */ >>>>> >>> #define PROT_EXEC 0x4 /* page can be executed */ >>>>> >>> #define PROT_SEM 0x8 /* page may be used for atomic ops */ >>>>> >>> +#define PROT_PKEY0 0x10 /* protection key value (bit 0) */ >>>>> >>> +#define PROT_PKEY1 0x20 /* protection key value (bit 1) */ >>>>> >>> +#define PROT_PKEY2 0x40 /* protection key value (bit 2) */ >>>>> >>> +#define PROT_PKEY3 0x80 /* protection key value (bit 3) */ >>>> >> >>>> >> Thats leaking deep Intelisms into asm-generic which makes me very >>>> >> uncomfortable. Whether we need to reserve some bits for "arch specific" >>>> >> is one question, what we do with them ought not to be leaking out. >>>> >> >>>> >> To start with trying to port code people will want to do >>>> >> >>>> >> #define PROT_PKEY0 0 >>>> >> #define PROT_PKEY1 0 >>> > >>> > Yeah, I feel pretty uncomfortable with it as well. I really don't >>> > expect these to live like this in asm-generic when I submit this. >>> > >>> > Powerpc and ia64 have _something_ resembling protection keys, so the >>> > concept isn't entirely x86 or Intel-specific. My hope would be that we >>> > do this in a way that other architectures can use. >> It will also be very painful to add additional bits. We went through >> this with the CPU affinity mask, and it still hurts it. Please use a >> more sensible interface from the start. :) > > Any suggestions? It's difficult. I don't know what kind of programming model you expect. Could glibc use these bits for its own implementation? Or OpenSSL? Or is this intended for tightly integrated language run-times which have a very precise idea what kind of stuff runs within the same address space? > Are you thinking that we want a completely separate syscall and > completely avoid using the PROT_* bits? Yes, that would seem more future-proof.