Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1219288 > unrolled thread

Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits to syscalls

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits  to syscalls Dave Hansen <dave@sr71.net> - 2015-09-04 22:20 +0200
    Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits to syscalls Florian Weimer <fw@deneb.enyo.de> - 2015-09-04 22:40 +0200
      Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits  to syscalls Dave Hansen <dave@sr71.net> - 2015-09-04 22:50 +0200

#1219288 — Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits to syscalls

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?

Are you thinking that we want a completely separate syscall and
completely avoid using the PROT_* bits?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1219295 — Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits to syscalls

* 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1219311

On 09/04/2015 01:34 PM, Florian Weimer wrote:
...>>> 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?

Our expectation is that there will be a central "allocator" for these
bits for mixed-use, like when two libraries want to control a portion of
the address space for their purposes.

Applications will also be completely free to implement their own, like
with a language runtime.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web