lkml.org 
[lkml]   [2015]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits to syscalls
Date
* 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.


\
 
 \ /
  Last update: 2015-09-04 22:41    [W:0.078 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site