On Fri, Jul 06, 2018 at 12:56:58PM -0700, Linus Torvalds wrote:
> On Fri, Jul 6, 2018 at 12:38 PM Mathieu Desnoyers
> wrote:
> >
> > Should I change all 4 bytes __get_user()/__put_user() in kernel/rseq.c
> > for get_user()/put_user() to ensure consistency ?
>
> Probably.
>
> *If* this actually
On Fri, Jul 06, 2018 at 12:56:58PM -0700, Linus Torvalds wrote:
> On Fri, Jul 6, 2018 at 12:38 PM Mathieu Desnoyers
> wrote:
> >
> > Should I change all 4 bytes __get_user()/__put_user() in kernel/rseq.c
> > for get_user()/put_user() to ensure consistency ?
>
> Probably.
>
> *If* this actually
On Fri, Jul 6, 2018 at 12:38 PM Mathieu Desnoyers
wrote:
>
> Should I change all 4 bytes __get_user()/__put_user() in kernel/rseq.c
> for get_user()/put_user() to ensure consistency ?
Probably.
*If* this actually turns out to be somethinig that shows up on
profiles, it's almost certainly going
On Fri, Jul 6, 2018 at 12:38 PM Mathieu Desnoyers
wrote:
>
> Should I change all 4 bytes __get_user()/__put_user() in kernel/rseq.c
> for get_user()/put_user() to ensure consistency ?
Probably.
*If* this actually turns out to be somethinig that shows up on
profiles, it's almost certainly going
On Fri, Jul 6, 2018 at 12:31 PM, Linus Torvalds
wrote:
> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
> wrote:
>>
>> For -rc, I would favor the following simpler approach. Or I could even
>> just use get_user() instead. Thoughts ?
>
> Please just use "get_user()".
>
> In fact, we should be
On Fri, Jul 6, 2018 at 12:31 PM, Linus Torvalds
wrote:
> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
> wrote:
>>
>> For -rc, I would favor the following simpler approach. Or I could even
>> just use get_user() instead. Thoughts ?
>
> Please just use "get_user()".
>
> In fact, we should be
- On Jul 6, 2018, at 3:35 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 6, 2018, at 3:31 PM, Linus Torvalds torva...@linux-foundation.org
> wrote:
>
>> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
>> wrote:
>>>
>>> For -rc, I would favor the following
- On Jul 6, 2018, at 3:35 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 6, 2018, at 3:31 PM, Linus Torvalds torva...@linux-foundation.org
> wrote:
>
>> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
>> wrote:
>>>
>>> For -rc, I would favor the following
- On Jul 6, 2018, at 3:31 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
> wrote:
>>
>> For -rc, I would favor the following simpler approach. Or I could even
>> just use get_user() instead. Thoughts ?
>
> Please just use
- On Jul 6, 2018, at 3:31 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
> wrote:
>>
>> For -rc, I would favor the following simpler approach. Or I could even
>> just use get_user() instead. Thoughts ?
>
> Please just use
On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
wrote:
>
> For -rc, I would favor the following simpler approach. Or I could even
> just use get_user() instead. Thoughts ?
Please just use "get_user()".
In fact, we should be thinking seriosly about just removing
__get_user() entirely. It's
On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
wrote:
>
> For -rc, I would favor the following simpler approach. Or I could even
> just use get_user() instead. Thoughts ?
Please just use "get_user()".
In fact, we should be thinking seriosly about just removing
__get_user() entirely. It's
- On Jul 6, 2018, at 12:02 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 5, 2018, at 2:05 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
[...]
> The 0-day bot noticed that __get_user() is unimplemented for 64-bit
> values on arm32 (although
- On Jul 6, 2018, at 12:02 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 5, 2018, at 2:05 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
[...]
> The 0-day bot noticed that __get_user() is unimplemented for 64-bit
> values on arm32 (although
- On Jul 5, 2018, at 2:05 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Declaring the rseq_cs field as a union between __u64 and two __u32
> allows both 32-bit and 64-bit kernels to read the full __u64, and
> therefore validate that a 32-bit user-space cleared the upper 32
>
- On Jul 5, 2018, at 2:05 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Declaring the rseq_cs field as a union between __u64 and two __u32
> allows both 32-bit and 64-bit kernels to read the full __u64, and
> therefore validate that a 32-bit user-space cleared the upper 32
>
Declaring the rseq_cs field as a union between __u64 and two __u32
allows both 32-bit and 64-bit kernels to read the full __u64, and
therefore validate that a 32-bit user-space cleared the upper 32
bits, thus ensuring a consistent behavior between native 32-bit
kernels and 32-bit compat tasks on
Declaring the rseq_cs field as a union between __u64 and two __u32
allows both 32-bit and 64-bit kernels to read the full __u64, and
therefore validate that a 32-bit user-space cleared the upper 32
bits, thus ensuring a consistent behavior between native 32-bit
kernels and 32-bit compat tasks on
18 matches
Mail list logo
