[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210104140952.GQ3021@hirez.programming.kicks-ass.net>
Date: Mon, 4 Jan 2021 15:09:52 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Juergen Gross <jgross@...e.com>, xen-devel@...ts.xenproject.org,
linux-kernel@...r.kernel.org, Miroslav Benes <mbenes@...e.cz>,
Shinichiro Kawasaki <shinichiro.kawasaki@....com>
Subject: Re: [PATCH 3/3] objtool: Support stack layout changes in alternatives
On Tue, Dec 22, 2020 at 11:18:10PM -0600, Josh Poimboeuf wrote:
> For example, this scenario is allowed:
>
> Alt1 Alt2 Alt3
>
> 0x00 CALL *pv_ops.save_fl CALL xen_save_fl PUSHF
> 0x01 POP %RAX
> 0x02 NOP
> ...
> 0x05 NOP
> ...
> 0x07 <insn>
>
> This scenario is NOT allowed:
>
> Alt1 Alt2
>
> 0x00 CALL *pv_ops.save_fl PUSHF
> 0x01 NOP6
> ...
> 0x07 NOP POP %RAX
>
> The problem here is that offset-0x7, which is an instruction boundary in
> both possible instruction patch streams, has two conflicting stack
> layouts.
There's another fun scenario:
0x00 CALL *pv_ops.save_fl PUSHF
0x01 NOP2
..
0x03 NOP5
..
0x07 NOP2
0x08 POP %RAX
0x09 <insn>
No conflicting boundary at 0x07, but still buggered.
Let me go read the actual patch to see if this is handled.
Powered by blists - more mailing lists