linux-kernel - Re: [PATCH v6 0/9] powerpc: Switch to CONFIG_THREAD_INFO_IN

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] [day] [month] [year] [list]

Date:   Tue, 9 Oct 2018 20:54:30 +1000
From:   Nicholas Piggin <npiggin@...il.com>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:     Christophe Leroy <christophe.leroy@....fr>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 0/9] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK

On Mon, 08 Oct 2018 20:59:56 +1100
Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:

> On Mon, 2018-10-08 at 09:16 +0000, Christophe Leroy wrote:
> > The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
> > moves the thread_info into task_struct.  
> 
> We need to make sure we don't have code that assumes that we don't take
> faults on TI access.
> 
> On ppc64, the stack SLB entries are bolted, which means the TI is too.
> 
> We might have code that assumes that we don't get SLB faults when
> accessing TI. If not, we're fine but that needs a close look.

Oh, we do. I think the entry side might be okay, but on exit we have
at least one (in syscall and interrupt exit both):

        /*
         * Disable interrupts so current_thread_info()->flags can't change,
         * and so that we don't get interrupted after loading SRR0/1.
         */
#ifdef CONFIG_PPC_BOOK3E
        wrteei  0
#else
        /*
         * For performance reasons we clear RI the same time that we
         * clear EE. We only need to clear RI just before we restore r13
         * below, but batching it with EE saves us one expensive mtmsrd call.
         * We have to be careful to restore RI if we branch anywhere from
         * here (eg syscall_exit_work).
         */
        li      r11,0
        mtmsrd  r11,1
#endif /* CONFIG_PPC_BOOK3E */

        ld      r9,TI_FLAGS(r12)

So taking an SLB there will cause an unrecoverable.

I think we can probably get rid of that optimization for now. I've found
for non-trivial syscalls it's often a loss if FP was used. I have a
couple of different options I'm working on to get rid of the mtmsrd
entirely we can go with instead (but I don't think those have to come
before Christophe's patch).

Thanks,
Nick