On Mon, Jul 2, 2018 at 1:13 PM Andy Lutomirski wrote:
>
> Like this:
>
> diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> index 3b2490b81918..ec40223c8856 100644
> --- a/arch/x86/entry/common.c
> +++ b/arch/x86/entry/common.c
> @@ -170,6 +170,26 @@ static void
On Mon, Jul 2, 2018 at 1:13 PM Andy Lutomirski wrote:
>
> Like this:
>
> diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> index 3b2490b81918..ec40223c8856 100644
> --- a/arch/x86/entry/common.c
> +++ b/arch/x86/entry/common.c
> @@ -170,6 +170,26 @@ static void
On Mon, Jul 2, 2018 at 12:31 PM, Linus Torvalds
wrote:
> On Mon, Jul 2, 2018 at 12:02 PM Andy Lutomirski wrote:
>>
>> Works for me. Linus, any objection?
>
> I think the 4.19 stage may be overkill, but I don't hate it, so no
> real objections.
>
> If the main reason for this is that we silently
On Mon, Jul 2, 2018 at 12:31 PM, Linus Torvalds
wrote:
> On Mon, Jul 2, 2018 at 12:02 PM Andy Lutomirski wrote:
>>
>> Works for me. Linus, any objection?
>
> I think the 4.19 stage may be overkill, but I don't hate it, so no
> real objections.
>
> If the main reason for this is that we silently
On Mon, Jul 2, 2018 at 12:02 PM Andy Lutomirski wrote:
>
> Works for me. Linus, any objection?
I think the 4.19 stage may be overkill, but I don't hate it, so no
real objections.
If the main reason for this is that we silently clear the upper bits
when returning to compat mode, I actually
On Mon, Jul 2, 2018 at 12:02 PM Andy Lutomirski wrote:
>
> Works for me. Linus, any objection?
I think the 4.19 stage may be overkill, but I don't hate it, so no
real objections.
If the main reason for this is that we silently clear the upper bits
when returning to compat mode, I actually
On Mon, Jul 2, 2018 at 12:00 PM, Mathieu Desnoyers
wrote:
> - On Jul 2, 2018, at 1:11 PM, Andy Lutomirski l...@amacapital.net wrote:
>>
>> But I think that the limited solution of changing
>> instruction_pointer_set() really is a sufficient
>> architecture-dependent change to fully solve your
On Mon, Jul 2, 2018 at 12:00 PM, Mathieu Desnoyers
wrote:
> - On Jul 2, 2018, at 1:11 PM, Andy Lutomirski l...@amacapital.net wrote:
>>
>> But I think that the limited solution of changing
>> instruction_pointer_set() really is a sufficient
>> architecture-dependent change to fully solve your
- On Jul 2, 2018, at 1:11 PM, Andy Lutomirski l...@amacapital.net wrote:
>
> But I think that the limited solution of changing
> instruction_pointer_set() really is a sufficient
> architecture-dependent change to fully solve your problem.
So let me recap with the changes I gather for 4.18
- On Jul 2, 2018, at 1:11 PM, Andy Lutomirski l...@amacapital.net wrote:
>
> But I think that the limited solution of changing
> instruction_pointer_set() really is a sufficient
> architecture-dependent change to fully solve your problem.
So let me recap with the changes I gather for 4.18
On Mon, Jul 2, 2018 at 7:32 AM Mathieu Desnoyers
wrote:
>
> - On Jun 29, 2018, at 4:39 PM, Andy Lutomirski l...@amacapital.net wrote:
>
> > On Fri, Jun 29, 2018 at 12:48 PM, Mathieu Desnoyers
> > wrote:
> >> There are two aspects I'm concerned about here:
> >>
> >> 1) security: we don't want
On Mon, Jul 2, 2018 at 7:32 AM Mathieu Desnoyers
wrote:
>
> - On Jun 29, 2018, at 4:39 PM, Andy Lutomirski l...@amacapital.net wrote:
>
> > On Fri, Jun 29, 2018 at 12:48 PM, Mathieu Desnoyers
> > wrote:
> >> There are two aspects I'm concerned about here:
> >>
> >> 1) security: we don't want
- On Jul 2, 2018, at 10:32 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
[...]
>
> But rather than trying to play games with input validation, I would
> favor an approach that would allow rseq to validate all its inputs
> straightforwardly. Introducing user_64bit_mode(struct
- On Jul 2, 2018, at 10:32 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
[...]
>
> But rather than trying to play games with input validation, I would
> favor an approach that would allow rseq to validate all its inputs
> straightforwardly. Introducing user_64bit_mode(struct
- On Jun 29, 2018, at 4:39 PM, Andy Lutomirski l...@amacapital.net wrote:
> On Fri, Jun 29, 2018 at 12:48 PM, Mathieu Desnoyers
> wrote:
>> There are two aspects I'm concerned about here:
>>
>> 1) security: we don't want 32-bit user-space to feed a 64-bit value over 4GB
>>as abort_ip
- On Jun 29, 2018, at 4:39 PM, Andy Lutomirski l...@amacapital.net wrote:
> On Fri, Jun 29, 2018 at 12:48 PM, Mathieu Desnoyers
> wrote:
>> There are two aspects I'm concerned about here:
>>
>> 1) security: we don't want 32-bit user-space to feed a 64-bit value over 4GB
>>as abort_ip
On Fri, Jun 29, 2018 at 12:48 PM, Mathieu Desnoyers
wrote:
> There are two aspects I'm concerned about here:
>
> 1) security: we don't want 32-bit user-space to feed a 64-bit value over 4GB
>as abort_ip that may end up causing OOPSes on architectures that would
>lack proper validation of
On Fri, Jun 29, 2018 at 12:48 PM, Mathieu Desnoyers
wrote:
> There are two aspects I'm concerned about here:
>
> 1) security: we don't want 32-bit user-space to feed a 64-bit value over 4GB
>as abort_ip that may end up causing OOPSes on architectures that would
>lack proper validation of
- On Jun 29, 2018, at 1:03 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Jun 29, 2018 at 9:07 AM Mathieu Desnoyers
> wrote:
>>
>> This code is not invoked from syscalls, but rather on return from
>> interrupt/trap after a preemption.
>
> But when we register the rseq,
- On Jun 29, 2018, at 1:03 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Jun 29, 2018 at 9:07 AM Mathieu Desnoyers
> wrote:
>>
>> This code is not invoked from syscalls, but rather on return from
>> interrupt/trap after a preemption.
>
> But when we register the rseq,
On Fri, Jun 29, 2018 at 9:07 AM Mathieu Desnoyers
wrote:
>
> This code is not invoked from syscalls, but rather on return from
> interrupt/trap after a preemption.
But when we register the rseq, we could easily check that the top bits
of the IP is clear, no?
Sure, user space can change it after
On Fri, Jun 29, 2018 at 9:07 AM Mathieu Desnoyers
wrote:
>
> This code is not invoked from syscalls, but rather on return from
> interrupt/trap after a preemption.
But when we register the rseq, we could easily check that the top bits
of the IP is clear, no?
Sure, user space can change it after
On Fri, Jun 29, 2018 at 8:27 AM, Linus Torvalds
wrote:
>
>
> On Fri, Jun 29, 2018, 08:03 Mathieu Desnoyers
> wrote:
>>
>>
>> Considering those inconsistencies between architectures (either
>> the task gets killed, or the top bits are silently cleared), I'm
>> very much tempted to be restrictive
On Fri, Jun 29, 2018 at 8:27 AM, Linus Torvalds
wrote:
>
>
> On Fri, Jun 29, 2018, 08:03 Mathieu Desnoyers
> wrote:
>>
>>
>> Considering those inconsistencies between architectures (either
>> the task gets killed, or the top bits are silently cleared), I'm
>> very much tempted to be restrictive
- On Jun 29, 2018, at 11:54 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
> On Fri, Jun 29, 2018 at 8:27 AM Linus Torvalds
> wrote:
>>
>> You simply can't have it both ways.
>
> Put another way.
>
> This is ok in the native path:
>
>if ((unsigned long) rseq_cs->abort_ip
- On Jun 29, 2018, at 11:54 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
> On Fri, Jun 29, 2018 at 8:27 AM Linus Torvalds
> wrote:
>>
>> You simply can't have it both ways.
>
> Put another way.
>
> This is ok in the native path:
>
>if ((unsigned long) rseq_cs->abort_ip
On Fri, Jun 29, 2018 at 8:27 AM Linus Torvalds
wrote:
>
> You simply can't have it both ways.
Put another way.
This is ok in the native path:
if ((unsigned long) rseq_cs->abort_ip != rseq_cs->abort_ip)
return -EINVAL;
because it's checking that the value fits in the
On Fri, Jun 29, 2018 at 8:27 AM Linus Torvalds
wrote:
>
> You simply can't have it both ways.
Put another way.
This is ok in the native path:
if ((unsigned long) rseq_cs->abort_ip != rseq_cs->abort_ip)
return -EINVAL;
because it's checking that the value fits in the
- On Jun 29, 2018, at 10:17 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
> On Fri, Jun 29, 2018 at 7:05 AM Mathieu Desnoyers
> wrote:
>>
>> What I'm worried about is setting regs->ip of a compat 32-bit task to
>> addresses in the range 0x1-0x.
>
> Well,
- On Jun 29, 2018, at 10:17 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
> On Fri, Jun 29, 2018 at 7:05 AM Mathieu Desnoyers
> wrote:
>>
>> What I'm worried about is setting regs->ip of a compat 32-bit task to
>> addresses in the range 0x1-0x.
>
> Well,
On Fri, Jun 29, 2018 at 7:05 AM Mathieu Desnoyers
wrote:
>
> What I'm worried about is setting regs->ip of a compat 32-bit task to
> addresses in the range 0x1-0x.
Well, they won't have anything mapped in that range, so it really
shouldn't matter.
Linus
On Fri, Jun 29, 2018 at 7:05 AM Mathieu Desnoyers
wrote:
>
> What I'm worried about is setting regs->ip of a compat 32-bit task to
> addresses in the range 0x1-0x.
Well, they won't have anything mapped in that range, so it really
shouldn't matter.
Linus
- On Jun 29, 2018, at 10:02 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
> On Thu, Jun 28, 2018 at 6:08 PM Andy Lutomirski wrote:
>> > On Jun 28, 2018, at 5:18 PM, Linus Torvalds
>> > wrote:
>> >
>> >
>> > Make it do
>> >
>> >if (rseq_cs->abort_ip != (unsigned
- On Jun 29, 2018, at 10:02 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
> On Thu, Jun 28, 2018 at 6:08 PM Andy Lutomirski wrote:
>> > On Jun 28, 2018, at 5:18 PM, Linus Torvalds
>> > wrote:
>> >
>> >
>> > Make it do
>> >
>> >if (rseq_cs->abort_ip != (unsigned
On Thu, Jun 28, 2018 at 6:08 PM Andy Lutomirski wrote:
> > On Jun 28, 2018, at 5:18 PM, Linus Torvalds
> > wrote:
> >
> >
> > Make it do
> >
> >if (rseq_cs->abort_ip != (unsigned long)rseq_cs->abort_ip)
> >return -EINVAL;
> >
> > at abort time.
>
> You sure? Because,
On Thu, Jun 28, 2018 at 6:08 PM Andy Lutomirski wrote:
> > On Jun 28, 2018, at 5:18 PM, Linus Torvalds
> > wrote:
> >
> >
> > Make it do
> >
> >if (rseq_cs->abort_ip != (unsigned long)rseq_cs->abort_ip)
> >return -EINVAL;
> >
> > at abort time.
>
> You sure? Because,
- On Jun 28, 2018, at 7:29 PM, Andy Lutomirski l...@kernel.org wrote:
> On Thu, Jun 28, 2018 at 2:22 PM, Linus Torvalds
> wrote:
>> On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>>>
>>> This is okay with me for a fix outside the merge window. Can you do a
>>> followup for the next
- On Jun 28, 2018, at 7:29 PM, Andy Lutomirski l...@kernel.org wrote:
> On Thu, Jun 28, 2018 at 2:22 PM, Linus Torvalds
> wrote:
>> On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>>>
>>> This is okay with me for a fix outside the merge window. Can you do a
>>> followup for the next
> On Jun 28, 2018, at 5:18 PM, Linus Torvalds
> wrote:
>
>> On Thu, Jun 28, 2018 at 4:30 PM Andy Lutomirski wrote:
>>
>> The idea is that, if someone screws up and sticks a number like
>> 0xbaadf00d00045678 into their rseq abort_ip in a 32-bit x86 program
>> (when they actually mean
> On Jun 28, 2018, at 5:18 PM, Linus Torvalds
> wrote:
>
>> On Thu, Jun 28, 2018 at 4:30 PM Andy Lutomirski wrote:
>>
>> The idea is that, if someone screws up and sticks a number like
>> 0xbaadf00d00045678 into their rseq abort_ip in a 32-bit x86 program
>> (when they actually mean
- On Jun 28, 2018, at 8:18 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Jun 28, 2018 at 4:30 PM Andy Lutomirski wrote:
>>
>> The idea is that, if someone screws up and sticks a number like
>> 0xbaadf00d00045678 into their rseq abort_ip in a 32-bit x86 program
>> (when
- On Jun 28, 2018, at 8:18 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Jun 28, 2018 at 4:30 PM Andy Lutomirski wrote:
>>
>> The idea is that, if someone screws up and sticks a number like
>> 0xbaadf00d00045678 into their rseq abort_ip in a 32-bit x86 program
>> (when
On Thu, Jun 28, 2018 at 4:30 PM Andy Lutomirski wrote:
>
> The idea is that, if someone screws up and sticks a number like
> 0xbaadf00d00045678 into their rseq abort_ip in a 32-bit x86 program
> (when they actually mean 0x00045678), we want to something consistent.
I think the "something
On Thu, Jun 28, 2018 at 4:30 PM Andy Lutomirski wrote:
>
> The idea is that, if someone screws up and sticks a number like
> 0xbaadf00d00045678 into their rseq abort_ip in a 32-bit x86 program
> (when they actually mean 0x00045678), we want to something consistent.
I think the "something
On Thu, Jun 28, 2018 at 2:22 PM, Linus Torvalds
wrote:
> On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>>
>> This is okay with me for a fix outside the merge window. Can you do a
>> followup for the next merge window that fixes it better, though? In
>> particular, TASK_SIZE is
On Thu, Jun 28, 2018 at 2:22 PM, Linus Torvalds
wrote:
> On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>>
>> This is okay with me for a fix outside the merge window. Can you do a
>> followup for the next merge window that fixes it better, though? In
>> particular, TASK_SIZE is
- On Jun 28, 2018, at 5:22 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>>
>> This is okay with me for a fix outside the merge window. Can you do a
>> followup for the next merge window that fixes it better, though? In
>>
- On Jun 28, 2018, at 5:22 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>>
>> This is okay with me for a fix outside the merge window. Can you do a
>> followup for the next merge window that fixes it better, though? In
>>
On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>
> This is okay with me for a fix outside the merge window. Can you do a
> followup for the next merge window that fixes it better, though? In
> particular, TASK_SIZE is generally garbage. I think a better fix
> would be something like
On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>
> This is okay with me for a fix outside the merge window. Can you do a
> followup for the next merge window that fixes it better, though? In
> particular, TASK_SIZE is generally garbage. I think a better fix
> would be something like
- On Jun 28, 2018, at 4:22 PM, Andy Lutomirski l...@kernel.org wrote:
> On Thu, Jun 28, 2018 at 9:23 AM, Mathieu Desnoyers
> wrote:
>> Validating the abort_ip field of rseq_cs ensures that the kernel don't
>> return to an invalid address when returning to userspace after an abort.
>> I don't
- On Jun 28, 2018, at 4:22 PM, Andy Lutomirski l...@kernel.org wrote:
> On Thu, Jun 28, 2018 at 9:23 AM, Mathieu Desnoyers
> wrote:
>> Validating the abort_ip field of rseq_cs ensures that the kernel don't
>> return to an invalid address when returning to userspace after an abort.
>> I don't
On Thu, Jun 28, 2018 at 9:23 AM, Mathieu Desnoyers
wrote:
> Validating the abort_ip field of rseq_cs ensures that the kernel don't
> return to an invalid address when returning to userspace after an abort.
> I don't fully trust each architecture code to cleanly deal with invalid
> return
On Thu, Jun 28, 2018 at 9:23 AM, Mathieu Desnoyers
wrote:
> Validating the abort_ip field of rseq_cs ensures that the kernel don't
> return to an invalid address when returning to userspace after an abort.
> I don't fully trust each architecture code to cleanly deal with invalid
> return
Validating the abort_ip field of rseq_cs ensures that the kernel don't
return to an invalid address when returning to userspace after an abort.
I don't fully trust each architecture code to cleanly deal with invalid
return addresses.
Validating the range [ start_ip, start_ip + post_commit_offset
Validating the abort_ip field of rseq_cs ensures that the kernel don't
return to an invalid address when returning to userspace after an abort.
I don't fully trust each architecture code to cleanly deal with invalid
return addresses.
Validating the range [ start_ip, start_ip + post_commit_offset
56 matches
Mail list logo
