Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2 1/3] objtool: check: Fully validate the stack frame
To:     Josh Poimboeuf <jpoimboe@redhat.com>
Cc:     linux-kernel@vger.kernel.org, peterz@infradead.org, mbenes@suse.cz,
        raphael.gault@arm.com, benh@kernel.crashing.org
References: <20200928093631.210610-1-jthierry@redhat.com>
 <20200928093631.210610-2-jthierry@redhat.com>
 <20200929191834.7daofidv6b5aef3y@treble>
 <5540c2a9-db13-e05e-713c-22ec00f21aa6@redhat.com>
 <20201012153500.owcyvgjv4m3t3nh3@treble>
From:   Julien Thierry <jthierry@redhat.com>
Message-ID: <1283e5a8-67e3-090c-0904-3d03ae10a178@redhat.com>
Date:   Tue, 13 Oct 2020 13:12:37 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <20201012153500.owcyvgjv4m3t3nh3@treble>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 10/12/20 4:35 PM, Josh Poimboeuf wrote:
> On Mon, Oct 12, 2020 at 11:21:49AM +0100, Julien Thierry wrote:
>> On 9/29/20 8:18 PM, Josh Poimboeuf wrote:
>>> "Stack frame" has more than one meaning now, I suppose.  i.e. it could
>>> also include the callee-saved registers and any other stack space
>>> allocated by the function.
>>>
>>> Would "call frame" be clearer?
>>>
>>>     CALL_FRAME_BP_OFFSET
>>>     CALL_FRAME_RA_OFFSET
>>>
>>> ?
>>
>> I would've thought that the call-frame could include the stackframe + other
>> callee saved regs.
> 
> Hm, probably so.
> 
>> Whereas stackframe tends to used for the caller's frame pointer +
>> return address (i.e. what allows unwinding). Unless I'm getting lost
>> with things.
> 
> I've always seen "stack frame" used to indicate the function's entire
> stack.
> 
>> And if call frame is associated with the region starting from the stack
>> pointer at the parent call point (since this is what CFA is), then it
>> shouldn't be associated with the framepointer + return address structure
>> since this could be anywhere on the call frame (not at a fixed offset) as
>> long as the new frame pointer points to the structure.
> 
> I suppose "call frame" and "stack frame" probably mean the same thing,
> in which case neither is appropriate here...
> 
> In fact, maybe we could forget the concept of a frame (or even a struct)
> here.
> 
> If cfa.base is CFI_BP, then is regs[CFI_BP].offset always the same as
> -cfa.offset?  i.e. could the BP checks could it just be a simple
> 
>    regs[CFI_BP].offset == -cfa.offset
> 
> check?
> 

I guess that makes sense. If the above was no true it would mean that BP 
is not pointing to the unwind information.

> And then is RA at regs[CFI_BP].offset + 8?
> 

In the case of aarch64, the saved frame pointer and return address 
appear in the same order as on x86_64. So that would work. If that can 
make things simpler for now I can go with that.

Thanks for the suggestion.

-- 
Julien Thierry