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:   Tue, 14 Apr 2020 20:31:23 +0200
From:   Alexandre Chartre <alexandre.chartre@...cle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, jpoimboe@...hat.com,
        jthierry@...hat.com, tglx@...utronix.de
Subject: Re: [PATCH V3 5/9] objtool: Add return address unwind hints



On 4/14/20 7:56 PM, Peter Zijlstra wrote:
> On Tue, Apr 14, 2020 at 06:40:12PM +0200, Alexandre Chartre wrote:
>>
>> On 4/14/20 6:16 PM, Peter Zijlstra wrote:
>>> On Tue, Apr 14, 2020 at 12:36:14PM +0200, Alexandre Chartre wrote:
>>>> Add the UNWIND_HINT_RADDR_DELETE and UNWIND_HINT_RADDR_ALTER unwind
>>>> hint macros to flag instructions which remove or modify return
>>>> addresses.
>>>
>>> I'm confused by this thing; why? AFAICT the rest of the patches are
>>> actually simpler without this one.
>>>
>>
>> This is required to indicate to objtool that assembly instructions are
>> changing return addresses. For example, in patch 8:
>>
>> For retpoline:
>>
>> @@ -88,6 +96,7 @@
>>   	lfence
>>   	jmp	.Lspec_trap_\@
>>   .Ldo_rop_\@:
>> +	UNWIND_HINT_RADDR_ALTER
>>   	mov	\reg, (%_ASM_SP)
>>   	ret
>>   .endm
>>
>> The unwind hint indicates that the return address has been altered, so the
>> code won't return to the return address which was on the stack.
> 
> But if you hadn't added that return stack stuff in the first place,
> you'd not have needed that HINT.
> 
> So what actual problem is it solving?
> 

The return stack stuff is here to correctly handle intra-function call so that
we can figure out where the ret of an intra-function call should return. We
don't have this challenge with regular functions because we know that a ret
inside such function just indicates the end of the function.

But when there's an intra-function call, a ret instruction can either:
   - continue after the intra-function call (if the stack was unchanged)
   - jump somewhere else (if the return address was changed) and eventually
     return to the next return address
   - indicate the end of the function (if the return address was removed).

So, all this is needed to correctly follow the flow of the code and properly
record stack changes.

alex.

Powered by blists - more mailing lists