Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 3/7] objtool: Add support for intra-function calls
To:     Josh Poimboeuf <jpoimboe@redhat.com>
Cc:     Alexandre Chartre <alexandre.chartre@oracle.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, peterz@infradead.org,
        tglx@linutronix.de
References: <20200402082220.808-1-alexandre.chartre@oracle.com>
 <20200402082220.808-4-alexandre.chartre@oracle.com>
 <db508586-258a-0616-d649-e76e95df9611@redhat.com>
 <20200402154919.2c6shw4hfreagchg@treble>
From:   Julien Thierry <jthierry@redhat.com>
Message-ID: <3d075cb2-8d99-5ab7-4842-efef1964247d@redhat.com>
Date:   Fri, 3 Apr 2020 09:01:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200402154919.2c6shw4hfreagchg@treble>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 4/2/20 4:49 PM, Josh Poimboeuf wrote:
> On Thu, Apr 02, 2020 at 01:53:49PM +0100, Julien Thierry wrote:
>> Hi Alexandre,
>>
>> I ran into the limitation of intra-function call for the arm64 support but
>> didn't take the time to make a clean patch to support them properly.
> 
> Can you give an example of where arm64 uses intra-function calls?  It
> sounds sketchy to me :-)  Is it really needed/useful?
> 

So the most notable/necessary one(s) is the one in tramp_ventry [1]. 
This macro is used as the begining of exception handlers for exceptions 
coming from userland. It was added as part of the mitigations of spectre 
(v1???).

To give some context, x30 is the register that "ret" instruction will 
use as return address, "bl" is the equivalent of x86 "call" and sets x30 
before jumping to the target address. (However, it doesn't have a 
special semantic for exception returns)

Note: I believe the comment about the return "stack" is about processor 
internal state (speculative thingies and all) rather than the actual 
stack, since the stack is untouched by that code. But I don't know the 
actual details.


There are also some in arch/arm64/crypto/crct10dif-ce-core.o , which is 
probably full of fast, smart and optimized code I don't understand :) . 
So I wouldn't feel confident commenting on whether those intra-function 
calls are needed or not.


Last I found is in qcom_link_stack_sanitization() [2], but that's just a 
workaround for a very specific hardware. In my local tree I just put the 
function as STACK_FRAME_NON_STANDARD. But the code just saves the return 
address, has 16 call instructions that just call the instruction after 
them, restores the return address and lets the C-function return 
normally (and it somehow fixes something for that hardware).


Those are the ones I stumbled on. So yes, it a bit sketchy, corner case 
code, but it's there and unlikely to go away.


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/entry.S?h=v5.6#n803

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/cpu_errata.c?h=v5.6#n195

Cheers,

-- 
Julien Thierry