linux-kernel - Re: [PATCH 2/2] x86/asm: Fix inline asm call constraints for clang

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 21 Sep 2017 07:52:15 -0400
From:   Brian Gerst <brgerst@...il.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "x86@...nel.org" <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexander Potapenko <glider@...gle.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Arnd Bergmann <arnd@...db.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>
Subject: Re: [PATCH 2/2] x86/asm: Fix inline asm call constraints for clang

On Thu, Sep 21, 2017 at 4:12 AM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Wed, Sep 20, 2017 at 11:19 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>>> On Wed, Sep 20, 2017 at 08:01:02PM +0200, Dmitry Vyukov wrote:
>>>>> On Wed, Sep 20, 2017 at 7:46 PM, H. Peter Anvin <hpa@...or.com> wrote:
>>>>>> On 09/20/17 10:38, Dmitry Vyukov wrote:
>>>>>>
>>>>>> I think we need just the frame itself and RSP pointing below this
>>>>>> frame. If we don't have a frame, CALL instruction will smash whatever
>>>>>> RSP happens to point to. Compiler doesn't have to setup RSP to point
>>>>>> below used part of stack in leaf functions.
>>>>>>
>>>>>
>>>>> In the kernel it does.  Redzoning is not allowed in the kernel, because
>>>>> interrupts or exceptions would also smash the redzone.
>>>>
>>>> I see... But it's the same for user-space signals, the first thing a
>>>> signal should do is to skip the redzone. I guess interrupt handlers
>>>> should switch to interrupt stack which avoids smashing redzone
>>>> altogether. Do you mean nested interrupts/exceptions in interrupts?
>>>> In my experience frames in leaf functions can have pretty large
>>>> performance penalty. Wonder if we have we considered changing
>>>> interrupt/exception handlers to avoid smashing redzones and disable
>>>> leaf frames?
>>>
>>> Currently, on x86-64, I believe all exceptions have their own dedicated
>>> stacks in the kernel, but IRQs still come in on the task's kernel stack.
>>>
>>> Andy, do you know if there's a reason why IRQs don't use a dedicated IST
>>> stack?
>>>
>>
>> Because IST is awful due to recursion issues.  We immediately switch to an IRQ stack, though.
>>
>> If the kernel wanted a redzone, it would have to use IST for everything, which would entail a bunch of unpleasant hackery.
>
> Thanks.
>
> I guess it must be finite recursion, because we could not handle
> infinite with finite stack. I thing that solves it is simply:
>
> sub $256, %rsp
> ... do stuff ...
> add $256, %rsp
>
> Don't know if it's applicable to interrupts or not.

No, it is not.  The processor pushes 5 or 6 words of data on the stack
(the IRET frame plus an error code for certain exceptions) before the
interrupt handler gets control.  So without using the IST for stack
switching on every interrupt, the redzone cannot be used in the kernel
as it will get smashed by the IRET frame.  In addition, since the
kernel's stack is limited in size, skipping 128 bytes on every
interrupt would overrun the stack faster.  The small gain from using
the redzone in the kernel is outweighed by these limitations.

--
Brian Gerst