linux-kernel - Re: Random shadow stack pointer corruption

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:   Sat, 18 Jul 2020 11:00:18 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Yu-cheng Yu <yu-cheng.yu@...el.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H.J. Lu" <hjl.tools@...il.com>, Ingo Molnar <mingo@...hat.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Tony Luck <tony.luck@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Weijiang Yang <weijiang.yang@...el.com>
Subject: Re: Random shadow stack pointer corruption

On Sat, Jul 18, 2020 at 10:58 AM Yu-cheng Yu <yu-cheng.yu@...el.com> wrote:
>
> Hi,
>
> My shadow stack tests start to have random shadow stack pointer corruption after
> v5.7 (excluding).  The symptom looks like some locking issue or the kernel is
> confused about which CPU a task is on.  In later tip/master, this can be
> triggered by creating two tasks and each does continuous
> pthread_create()/pthread_join().  If the kernel has max_cpus=1, the issue goes
> away.  I also checked XSAVES/XRSTORS, but this does not seem to be an issue
> coming from there.

What do you mean "shadow stack pointer corruption"?  Is SSP itself
corrupt while running in the kernel?  Is one of the MSRs getting
corrupted?  Is the memory to which the shadow stack points getting
corrupted? Is the CPU rejecting an attempt to change SSP?

--Andy

>
> The tests I run take a long time to complete, and some commit points in bisect
> do not show failures right away.  However, the issue can be more easily
> triggered after the point of:
>
> d77290507ab2 x86/entry/32: Convert IRET exception to IDTENTRY_SW
>
> Can anyone help me find places to look at?
>
> Thanks,
> Yu-cheng
>