On 10/19/2018 10:37 AM, Andy Lutomirski wrote:
>> I think it's much more straightforward to just not enforce pkeys.
>> Having this "phantom" value could cause a very odd, nearly
>> undebuggable I/O failure.
> But now we have the reverse. The IO can work if it’s truly async but,
> if the kernel
On 10/19/2018 10:37 AM, Andy Lutomirski wrote:
>> I think it's much more straightforward to just not enforce pkeys.
>> Having this "phantom" value could cause a very odd, nearly
>> undebuggable I/O failure.
> But now we have the reverse. The IO can work if it’s truly async but,
> if the kernel
> On Oct 19, 2018, at 10:01 AM, Dave Hansen wrote:
>
> On 10/19/2018 09:59 AM, Andy Lutomirski wrote:
>>> That looks like a good API in general. The ffs_user_copy_worker that
>>> Sebastian mentioned seems to be used by AIO, in which case of course it
>>> has to happen in a kernel thread.
>>>
> On Oct 19, 2018, at 10:01 AM, Dave Hansen wrote:
>
> On 10/19/2018 09:59 AM, Andy Lutomirski wrote:
>>> That looks like a good API in general. The ffs_user_copy_worker that
>>> Sebastian mentioned seems to be used by AIO, in which case of course it
>>> has to happen in a kernel thread.
>>>
On 10/19/2018 09:59 AM, Andy Lutomirski wrote:
>> That looks like a good API in general. The ffs_user_copy_worker that
>> Sebastian mentioned seems to be used by AIO, in which case of course it
>> has to happen in a kernel thread.
>>
>> But while the API is good, deciding on the desired semantics
On 10/19/2018 09:59 AM, Andy Lutomirski wrote:
>> That looks like a good API in general. The ffs_user_copy_worker that
>> Sebastian mentioned seems to be used by AIO, in which case of course it
>> has to happen in a kernel thread.
>>
>> But while the API is good, deciding on the desired semantics
> On Oct 19, 2018, at 12:44 AM, Paolo Bonzini wrote:
>
> On 18/10/2018 22:46, Andy Lutomirski wrote:
>>> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker()
>>>
>>> Sebastian
>> I think we need an entirely new API:
>>
>> user_mm_ctx_t ctx = user_mm_ctx_get();
>>
>> ...
>>
>>
> On Oct 19, 2018, at 12:44 AM, Paolo Bonzini wrote:
>
> On 18/10/2018 22:46, Andy Lutomirski wrote:
>>> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker()
>>>
>>> Sebastian
>> I think we need an entirely new API:
>>
>> user_mm_ctx_t ctx = user_mm_ctx_get();
>>
>> ...
>>
>>
On 18/10/2018 22:46, Andy Lutomirski wrote:
>> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker()
>>
>> Sebastian
> I think we need an entirely new API:
>
> user_mm_ctx_t ctx = user_mm_ctx_get();
>
> ...
>
> use_user_mm_ctx(ctx);
> unuse_user_mm_ctx(ctx);
>
> ...
>
>
On 18/10/2018 22:46, Andy Lutomirski wrote:
>> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker()
>>
>> Sebastian
> I think we need an entirely new API:
>
> user_mm_ctx_t ctx = user_mm_ctx_get();
>
> ...
>
> use_user_mm_ctx(ctx);
> unuse_user_mm_ctx(ctx);
>
> ...
>
>
> On Oct 18, 2018, at 2:24 PM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-10-18 13:56:24 [-0700], Dave Hansen wrote:
>>> But this is not the only loophole: There is ptrace interface which is
>>> used by gdb (just checked) and also bypasses PKRU. So…
>>
>> Bypassing protection keys is
> On Oct 18, 2018, at 2:24 PM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-10-18 13:56:24 [-0700], Dave Hansen wrote:
>>> But this is not the only loophole: There is ptrace interface which is
>>> used by gdb (just checked) and also bypasses PKRU. So…
>>
>> Bypassing protection keys is
On 2018-10-18 13:56:24 [-0700], Dave Hansen wrote:
> > But this is not the only loophole: There is ptrace interface which is
> > used by gdb (just checked) and also bypasses PKRU. So…
>
> Bypassing protection keys is not a big deal IMNHO. In places where a
> sane one is not readily available,
On 2018-10-18 13:56:24 [-0700], Dave Hansen wrote:
> > But this is not the only loophole: There is ptrace interface which is
> > used by gdb (just checked) and also bypasses PKRU. So…
>
> Bypassing protection keys is not a big deal IMNHO. In places where a
> sane one is not readily available,
On 10/18/2018 01:46 PM, Andy Lutomirski wrote:
> Setting it to allow-all/none would let the operation always fail or
> succeed which might be an improvement in terms of debugging. However it
> is hard to judge what the correct behaviour should be. Should fail or
> succeed.
Succeed. :)
> But this
On 10/18/2018 01:46 PM, Andy Lutomirski wrote:
> Setting it to allow-all/none would let the operation always fail or
> succeed which might be an improvement in terms of debugging. However it
> is hard to judge what the correct behaviour should be. Should fail or
> succeed.
Succeed. :)
> But this
On Thu, Oct 18, 2018 at 11:25 AM Sebastian Andrzej Siewior
wrote:
>
> On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote:
> > > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior
> > > wrote:
> > >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> > >> On Fri, Oct 12, 2018 at
On Thu, Oct 18, 2018 at 11:25 AM Sebastian Andrzej Siewior
wrote:
>
> On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote:
> > > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior
> > > wrote:
> > >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> > >> On Fri, Oct 12, 2018 at
On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote:
> > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior
> > wrote:
> >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> >> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
> >>> So I'm kinda missing the point of the patch.
> >>
> >>
On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote:
> > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior
> > wrote:
> >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> >> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
> >>> So I'm kinda missing the point of the patch.
> >>
> >>
On 10/18/2018 09:48 AM, Andy Lutomirski wrote:
We might want to do this for cleanliness reasons... Maybe.
But this *should* have no practical effects. Kernel threads have no
real 'mm' and no user pages. They should not have do access to user
mappings. Protection keys
On 10/18/2018 09:48 AM, Andy Lutomirski wrote:
We might want to do this for cleanliness reasons... Maybe.
But this *should* have no practical effects. Kernel threads have no
real 'mm' and no user pages. They should not have do access to user
mappings. Protection keys
> On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior
> wrote:
>
>> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
>> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
>> wrote:
>>>
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
The PKRU value is not set for
> On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior
> wrote:
>
>> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
>> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
>> wrote:
>>>
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
The PKRU value is not set for
On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
> wrote:
> >
> > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > > The PKRU value is not set for kernel threads because they do not have
> > > the ->initialized value set. As a
On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
> wrote:
> >
> > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > > The PKRU value is not set for kernel threads because they do not have
> > > the ->initialized value set. As a
On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The PKRU value is not set for kernel threads because they do not have
> > the ->initialized value set. As a result the kernel thread has a random
> > PKRU value set which it
On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The PKRU value is not set for kernel threads because they do not have
> > the ->initialized value set. As a result the kernel thread has a random
> > PKRU value set which it
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The PKRU value is not set for kernel threads because they do not have
> the ->initialized value set. As a result the kernel thread has a random
> PKRU value set which it inherits from the previous task.
> It has been suggested by Paolo
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The PKRU value is not set for kernel threads because they do not have
> the ->initialized value set. As a result the kernel thread has a random
> PKRU value set which it inherits from the previous task.
> It has been suggested by Paolo
30 matches
Mail list logo
