linux-kernel - Re: [PATCH V2 5/9] objtool: Add support for intra-function calls

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]

Date:   Wed, 8 Apr 2020 18:03:35 +0200
From:   Alexandre Chartre <alexandre.chartre@...cle.com>
To:     Julien Thierry <jthierry@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, jpoimboe@...hat.com,
        tglx@...utronix.de
Subject: Re: [PATCH V2 5/9] objtool: Add support for intra-function calls



On 4/8/20 4:19 PM, Julien Thierry wrote:
> 
> 
> On 4/8/20 3:06 PM, Alexandre Chartre wrote:
>>
>>
>> On 4/7/20 3:28 PM, Alexandre Chartre wrote:
>>>
>>> On 4/7/20 3:07 PM, Peter Zijlstra wrote:
>>>> On Tue, Apr 07, 2020 at 09:31:38AM +0200, Alexandre Chartre wrote:
>>>>
>>>>> index a62e032863a8..7ee1561bf7ad 100644
>>>>> --- a/tools/objtool/arch/x86/decode.c
>>>>> +++ b/tools/objtool/arch/x86/decode.c
>>>>> @@ -497,3 +497,15 @@ void arch_initial_func_cfi_state(struct cfi_state *state)
>>>>>       state->regs[16].base = CFI_CFA;
>>>>>       state->regs[16].offset = -8;
>>>>>   }
>>>>> +
>>>>> +
>>>>> +void arch_configure_intra_function_call(struct stack_op *op)
>>>>> +{
>>>>> +    /*
>>>>> +     * For the impact on the stack, make an intra-function
>>>>> +     * call behaves like a push of an immediate value (the
>>>>> +     * return address).
>>>>> +     */
>>>>> +    op->src.type = OP_SRC_CONST;
>>>>> +    op->dest.type = OP_DEST_PUSH;
>>>>> +}
>>>>
>>>> An alternative is to always set up stack ops for CALL/RET on decode, but
>>>> conditionally run update_insn_state() for them.
>>>>
>>>> Not sure that makes more logical sense, but the patch would be simpler I
>>>> think.
>>>
>>> Right, this would avoid adding a new arch dependent function and the patch
>>> will be simpler. This probably makes sense as the stack impact is the same
>>> for all calls (but objtool will use it only for intra-function calls).
>>>
>>
>> Actually the processing of the ret instruction is more complicated than I
>> anticipated with intra-function calls, and so my implementation is not
>> complete at the moment.
>>
>> The issue is to correctly handle how the ret is going to behave depending how
>> the stack (or register on arm) is modified before the ret. Adjusting the stack
>> offset makes the stack state correct, but objtool still needs to correctly
>> figure out where the ret is going to return and where the code flow continues.
>>
> 
> A hint indicating the target "jump" address could be useful. It could
> be used to add the information on some call/jump dynamic that aren't
> associated with jump tables. Currently when objtool finds a jump
> dynamic, if no branches were added to it, it will just return.
> 
> Having such a hint could help make additional links (at least on
> arm64). I don't know what Peter and Josh would think of that (if that
> helps in your case of course).
> 

Yes, I am thinking about tracking intra-function call return address,
and having hints to specify a return address changes. For example,
on x86, when we push the branch address on the stack we overwrite the
last return address (the return address of the last intra-function call).
Then the return instruction can figure out where to branch.

alex.