linux-kernel - Re: [patch V3 02/20] x86/process: Unify copy_thread

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, 13 Nov 2019 16:44:39 -0500
From:   Brian Gerst <brgerst@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Willy Tarreau <w@....eu>, Juergen Gross <jgross@...e.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [patch V3 02/20] x86/process: Unify copy_thread_tls()

On Wed, Nov 13, 2019 at 4:14 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Wed, Nov 13, 2019 at 1:02 PM Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > +int copy_thread_tls(unsigned long clone_flags, unsigned long sp,
> > +                   unsigned long arg, struct task_struct *p, unsigned long tls)
> ...
> > +#ifdef CONFIG_X86_64
> ..
> > +#else
> > +       /* Clear all status flags including IF and set fixed bit. */
> > +       frame->flags = X86_EFLAGS_FIXED;
> > +#endif
>
> Hmm. The unification I like, but it also shows these differences that
> I don't remember the reason for.
>
> Remind me why __switch_to_asm() on 32-bit safes eflags, but we don't
> do it on x86-64?
>
> The comment just talks about callee-saved registers, but flags isn't
> callee-saved, so there's something else going on.
>
> This patch clearly doesn't change anything, I'm not complaining about
> the patch at all. I'm just wondering about the odd difference that the
> patch exposes.

It's to prevent AC from leaking into the next task.  objtool can
verify that 64-bit code doesn't schedule when AC is set, but it
doesn't work on 32-bit.  We could probably just do a CLAC on switch
and when it switches back to that task you would get an oops and it
would get noticed.  It's likely though that the 64-bit coverage has
fixed most of the places where this happened.

--
Brian Gerst