On 07/09/2016 01:37 AM, Ingo Molnar wrote:
> - There are 16 pkey indices on x86 currently. We already use index 15 for
> the
>true PROT_EXEC implementation. Let's set aside another pkey index for the
>kernel's potential future use (index 14), and clear it explicitly in the
>FPU con
On 07/09/2016 01:37 AM, Ingo Molnar wrote:
>I.e. this pattern:
>
> ret = pkey_mprotect(NULL, PAGE_SIZE, real_prot, pkey);
>
>... would validate the pkey and we'd return -EOPNOTSUPP for pkey that is
> not
>available? This would allow maximum future flexibility as it would not
>
* Andy Lutomirski wrote:
> On Thu, Jul 14, 2016 at 1:07 AM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> On Wed, Jul 13, 2016 at 12:56 AM, Ingo Molnar wrote:
> >> >
> >> > * Andy Lutomirski wrote:
> >> >
> >> >> > If we push a PKRU value into a thread between the rdpkru() and
On Thu, Jul 14, 2016 at 1:07 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> On Wed, Jul 13, 2016 at 12:56 AM, Ingo Molnar wrote:
>> >
>> > * Andy Lutomirski wrote:
>> >
>> >> > If we push a PKRU value into a thread between the rdpkru() and
>> >> > wrpkru(), we'll
>> >> > lose the con
* Andy Lutomirski wrote:
> On Wed, Jul 13, 2016 at 12:56 AM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> > If we push a PKRU value into a thread between the rdpkru() and wrpkru(),
> >> > we'll
> >> > lose the content of that "push". I'm not sure there's any way to
> >> > gu
On Wed, Jul 13, 2016 at 12:56 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> > If we push a PKRU value into a thread between the rdpkru() and wrpkru(),
>> > we'll
>> > lose the content of that "push". I'm not sure there's any way to guarantee
>> > this with a user-controlled register.
* Andy Lutomirski wrote:
> > If we push a PKRU value into a thread between the rdpkru() and wrpkru(),
> > we'll
> > lose the content of that "push". I'm not sure there's any way to guarantee
> > this with a user-controlled register.
>
> We could try to insist that user code uses some vsysca
On Tue, Jul 12, 2016 at 10:12 AM, Dave Hansen wrote:
> On 07/12/2016 09:32 AM, Andy Lutomirski wrote:
>> I think it's more or less impossible to get sensible behavior passing
>> pkey != 0 data to legacy functions. If you call:
>>
>> void frob(struct foo *p);
>>
>> If frob in turn passes p to a th
On 07/12/2016 09:32 AM, Andy Lutomirski wrote:
> I think it's more or less impossible to get sensible behavior passing
> pkey != 0 data to legacy functions. If you call:
>
> void frob(struct foo *p);
>
> If frob in turn passes p to a thread, what PKRU is it supposed to use?
The thread inheritan
On Jul 11, 2016 8:48 AM, "Dave Hansen" wrote:
>
> On 07/11/2016 07:45 AM, Andy Lutomirski wrote:
> > On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen wrote:
> >> Should we instead just recommend to userspace that they lock down access
> >> to keys by default in all threads as a best practice?
> >
> >
On 07/12/2016 12:13 AM, Ingo Molnar wrote:
>> > Remember, PKRU is just a *bitmap*. The only place keys are stored is in
>> > the
>> > page tables.
> A pkey is an index *and* a protection mask. So by representing it as a
> bitmask we
> lose per thread information. This is what I meant by 'incom
* Dave Hansen wrote:
> On 07/11/2016 12:35 AM, Ingo Molnar wrote:
> > * Andy Lutomirski wrote:
> > mprotect_pkey()'s effects are per MM, but the system calls related to
> > managing the
> > keys (alloc/free/get/set) are fundamentally per CPU.
> >
> > Here's an example of how this could matte
On 07/11/2016 07:45 AM, Andy Lutomirski wrote:
> On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen wrote:
>> Should we instead just recommend to userspace that they lock down access
>> to keys by default in all threads as a best practice?
>
> Is that really better than doing it in-kernel? My concern
On Mon, Jul 11, 2016 at 12:35 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> On Jul 9, 2016 1:37 AM, "Ingo Molnar" wrote:
>> >
>> >
>> > * Dave Hansen wrote:
>> >
>> > > On 07/08/2016 12:18 AM, Ingo Molnar wrote:
>> > >
>> > > > So the question is, what is user-space going to do? Do a
On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen wrote:
> On 07/10/2016 09:25 PM, Andy Lutomirski wrote:
>> 2. When thread A allocates a pkey, how does it lock down thread B?
>>
>> #2 could be addressed by using fully-locked-down as the initial state
>> post-exec() and copying the state on clone(). D
On 07/10/2016 09:25 PM, Andy Lutomirski wrote:
> 2. When thread A allocates a pkey, how does it lock down thread B?
>
> #2 could be addressed by using fully-locked-down as the initial state
> post-exec() and copying the state on clone(). Dave, are there any
> cases in practice where one thread wo
On 07/11/2016 12:35 AM, Ingo Molnar wrote:
> * Andy Lutomirski wrote:
> mprotect_pkey()'s effects are per MM, but the system calls related to
> managing the
> keys (alloc/free/get/set) are fundamentally per CPU.
>
> Here's an example of how this could matter to applications:
>
> - 'writer thr
* Andy Lutomirski wrote:
> On Jul 9, 2016 1:37 AM, "Ingo Molnar" wrote:
> >
> >
> > * Dave Hansen wrote:
> >
> > > On 07/08/2016 12:18 AM, Ingo Molnar wrote:
> > >
> > > > So the question is, what is user-space going to do? Do any glibc patches
> > > > exist? How are the user-space library sid
On Jul 9, 2016 1:37 AM, "Ingo Molnar" wrote:
>
>
> * Dave Hansen wrote:
>
> > On 07/08/2016 12:18 AM, Ingo Molnar wrote:
> >
> > > So the question is, what is user-space going to do? Do any glibc patches
> > > exist? How are the user-space library side APIs going to look like?
> >
> > My goal at
* Dave Hansen wrote:
> On 07/08/2016 12:18 AM, Ingo Molnar wrote:
>
> > So the question is, what is user-space going to do? Do any glibc patches
> > exist? How are the user-space library side APIs going to look like?
>
> My goal at the moment is to get folks enabled to the point that they can
On 07/08/2016 12:18 AM, Ingo Molnar wrote:
> So my hope was that we'd also grow some debugging features: such as a
> periodic
> watchdog timer clearing all non-allocated pkeys of a task and re-setting them
> to
> their (kernel-)known values and thus forcing user-space to coordinate key
> alloc
On 07/08/2016 12:18 AM, Ingo Molnar wrote:
> So the question is, what is user-space going to do? Do any glibc
> patches exist? How are the user-space library side APIs going to look
> like?
My goal at the moment is to get folks enabled to the point that they can
start modifying apps to use pkeys w
On Thu, Jul 07, 2016 at 10:33:00AM -0700, Dave Hansen wrote:
> On 07/07/2016 07:45 AM, Mel Gorman wrote:
> > On Thu, Jul 07, 2016 at 05:47:28AM -0700, Dave Hansen wrote:
> >> >
> >> > From: Dave Hansen
> >> >
> >> > This establishes two more system calls for protection key management:
> >> >
>
* Dave Hansen wrote:
> > Applications that frequently get called will get hammed into the ground
> > with
> > serialisation on mmap_sem not to mention the cost of the syscall entry/exit.
>
> I think we can do both of them without mmap_sem, as long as we resign
> ourselves
> to this just bein
On 07/07/2016 07:45 AM, Mel Gorman wrote:
> On Thu, Jul 07, 2016 at 05:47:28AM -0700, Dave Hansen wrote:
>> >
>> > From: Dave Hansen
>> >
>> > This establishes two more system calls for protection key management:
>> >
>> >unsigned long pkey_get(int pkey);
>> >int pkey_set(int pkey, unsi
On Thu, Jul 07, 2016 at 05:47:28AM -0700, Dave Hansen wrote:
>
> From: Dave Hansen
>
> This establishes two more system calls for protection key management:
>
> unsigned long pkey_get(int pkey);
> int pkey_set(int pkey, unsigned long access_rights);
>
> The return value from pkey_g
26 matches
Mail list logo
