linux-kernel - Re: Question: livepatch failed for new fork() task stack unreliable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200604024051.6ovbr6tbrowwg6jr@treble>
Date:   Wed, 3 Jun 2020 21:40:51 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     "Wangshaobo (bobo)" <bobo.shaobowang@...wei.com>
Cc:     huawei.libin@...wei.com, xiexiuqi@...wei.com,
        cj.chengjian@...wei.com, mingo@...hat.com, x86@...nel.org,
        linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
        mbenes@...e.cz, devel@...ukata.com, viro@...iv.linux.org.uk,
        esyr@...hat.com
Subject: Re: Question: livepatch failed for new fork() task stack unreliable

On Thu, Jun 04, 2020 at 09:24:55AM +0800, Wangshaobo (bobo) wrote:
> 
> 在 2020/6/3 23:33, Josh Poimboeuf 写道:
> > On Wed, Jun 03, 2020 at 10:06:07PM +0800, Wangshaobo (bobo) wrote:
> > To be honest, I don't remember what I meant by sibling calls.  They
> > don't even leave anything on the stack.
> > 
> > For noreturns, the code might be laid out like this:
> > 
> > func1:
> > 	...
> > 	call noreturn_foo
> > func2:
> > 
> > func2 is immediately after the call to noreturn_foo.  So the return
> > address on the stack will actually be 'func2'.  We want to retrieve the
> > ORC data for the call instruction (inside func1), instead of the
> > instruction at the beginning of func2.
> > 
> > I should probably update that comment.
> 
> So, I want to ask is there any side effects if i modify like this ? this
> modification is based on
> 
> your fix. It looks like ok with proper test.
> 
> diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> index e9cc182aa97e..ecce5051e8fd 100644
> --- a/arch/x86/kernel/unwind_orc.c
> +++ b/arch/x86/kernel/unwind_orc.c
> @@ -620,6 +620,7 @@ void __unwind_start(struct unwind_state *state, struct
> task_struct *task,
>                 state->sp = task->thread.sp;
>                 state->bp = READ_ONCE_NOCHECK(frame->bp);
>                 state->ip = READ_ONCE_NOCHECK(frame->ret_addr);
> +              state->signal = ((void *)state->ip == ret_from_fork);
>         }
> 
> diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> index 7f969b2d240f..d7396431261a 100644
> --- a/arch/x86/kernel/unwind_orc.c
> +++ b/arch/x86/kernel/unwind_orc.c
> @@ -540,7 +540,7 @@ bool unwind_next_frame(struct unwind_state *state)
>          state->sp = sp;
>          state->regs = NULL;
>          state->prev_regs = NULL;
> -        state->signal = ((void *)state->ip == ret_from_fork);
> +        state->signal = false;
>          break;

Yes that's correct.

-- 
Josh