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]
Message-ID: <4c8e8e28-9802-fb8f-1b33-5247622233e0@virtuozzo.com>
Date:   Mon, 15 Jan 2018 17:37:02 +0300
From:   Andrey Ryabinin <aryabinin@...tuozzo.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Cc:     stable@...r.kernel.org, Josh Poimboeuf <jpoimboe@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [PATCH 4.9 84/96] x86/asm: Use register variable to get stack
 pointer value

Resending with correct David's email s/dwmw@...zon.co.ku/dwmw@...zon.co.uk/
(it's incorrect in signed-off-by line)

On 01/15/2018 05:31 PM, Andrey Ryabinin wrote:
> 
> 
> On 01/15/2018 03:35 PM, Greg Kroah-Hartman wrote:
>> 4.9-stable review patch.  If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Andrey Ryabinin <aryabinin@...tuozzo.com>
>>
>> commit 196bd485ee4f03ce4c690bfcf38138abfcd0a4bc upstream.
>>
>> Currently we use current_stack_pointer() function to get the value
>> of the stack pointer register. Since commit:
>>
>>   f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang")
>>
>> ... we have a stack register variable declared. It can be used instead of
>> current_stack_pointer() function which allows to optimize away some
>> excessive "mov %rsp, %<dst>" instructions:
>>
>>  -mov    %rsp,%rdx
>>  -sub    %rdx,%rax
>>  -cmp    $0x3fff,%rax
>>  -ja     ffffffff810722fd <ist_begin_non_atomic+0x2d>
>>
>>  +sub    %rsp,%rax
>>  +cmp    $0x3fff,%rax
>>  +ja     ffffffff810722fa <ist_begin_non_atomic+0x2a>
>>
>> Remove current_stack_pointer(), rename __asm_call_sp to current_stack_pointer
>> and use it instead of the removed function.
>>
>> Signed-off-by: Andrey Ryabinin <aryabinin@...tuozzo.com>
>> Reviewed-by: Josh Poimboeuf <jpoimboe@...hat.com>
>> Cc: Andy Lutomirski <luto@...nel.org>
>> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
>> Cc: Peter Zijlstra <peterz@...radead.org>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Link: http://lkml.kernel.org/r/20170929141537.29167-1-aryabinin@virtuozzo.com
>> Signed-off-by: Ingo Molnar <mingo@...nel.org>
>> [dwmw2: We want ASM_CALL_CONSTRAINT for retpoline]
> 
> If we want ASM_CALL_CONSTRAINT it would be more correct to backport
>   f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang")
> and some fixes for it:
>   520a13c530ae ("x86/asm: Fix inline asm call constraints for GCC 4.4")
>   ca26cffa4e4a ("x86/asm: Allow again using asm.h when building for the 'bpf' clang target")
> 
> Because ASM_CALL_CONSTRAINT added in f5caf621ee35, not in this patch.
> 
> The end result looks fine though. So it's ok to keep it that way.
> 
> 
>> Signed-off-by: David Woodhouse <dwmw@...zon.co.ku>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>> ---
>>  arch/x86/include/asm/asm.h         |   11 +++++++++++
>>  arch/x86/include/asm/thread_info.h |   11 -----------
>>  arch/x86/kernel/irq_32.c           |    6 +++---
>>  arch/x86/kernel/traps.c            |    2 +-
>>  arch/x86/mm/tlb.c                  |    2 +-
>>  5 files changed, 16 insertions(+), 16 deletions(-)
>>
>> --- a/arch/x86/include/asm/asm.h
>> +++ b/arch/x86/include/asm/asm.h
>> @@ -125,4 +125,15 @@
>>  /* For C file, we already have NOKPROBE_SYMBOL macro */
>>  #endif
>>  
>> +#ifndef __ASSEMBLY__
>> +/*
>> + * This output constraint should be used for any inline asm which has a "call"
>> + * instruction.  Otherwise the asm may be inserted before the frame pointer
>> + * gets set up by the containing function.  If you forget to do this, objtool
>> + * may print a "call without frame pointer save/setup" warning.
>> + */
>> +register unsigned long current_stack_pointer asm(_ASM_SP);
>> +#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
>> +#endif
>> +
>>  #endif /* _ASM_X86_ASM_H */

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ