linux-kernel - Re: linux-next: manual merge of the tip tree with Linus' tree

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:   Tue, 6 Feb 2018 13:55:12 +0000
From:   Will Deacon <will.deacon@....com>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: manual merge of the tip tree with Linus' tree

On Tue, Feb 06, 2018 at 12:52:34PM +0000, Mathieu Desnoyers wrote:
> ----- On Feb 5, 2018, at 7:40 PM, Stephen Rothwell sfr@...b.auug.org.au wrote:
> 
> > Hi all,
> > 
> > Today's linux-next merge of the tip tree got a conflict in:
> > 
> >  arch/arm64/kernel/entry.S
> > 
> > between commit:
> > 
> >  4bf3286d29f3 ("arm64: entry: Hook up entry trampoline to exception vectors")
> > 
> > from Linus' tree and commit:
> > 
> >  f1e3a12b6543 ("membarrier/arm64: Provide core serializing command")
> > 
> > from the tip tree.
> > 
> > I fixed it up (probably not completely - see below) and can carry the
> > fix as necessary. This is now fixed as far as linux-next is concerned,
> > but any non trivial conflicts should be mentioned to your upstream
> > maintainer when your tree is submitted for merging.  You may also want
> > to consider cooperating with the maintainer of the conflicting tree to
> > minimise any particularly complex conflicts.
> 
> The change introduced by 4bf3286d29 "arm64: entry: Hook up entry trampoline
> to exception vectors" adds a trampoline as mechanism for return:
> 
> -       eret                                    // return to kernel
> +
> +#ifndef CONFIG_UNMAP_KERNEL_AT_EL0
> +       eret
> +#else
> +       .if     \el == 0
> +       bne     4f
> +       msr     far_el1, x30
> +       tramp_alias     x30, tramp_exit_native
> +       br      x30
> +4:
> +       tramp_alias     x30, tramp_exit_compat
> +       br      x30
> +       .else
> +       eret
> +       .endif
> +#endif
> 
> Which means that with CONFIG_UNMAP_KERNEL_AT_EL0, for return to EL0,
> the eret is in the trampoline:
> 
>         .macro tramp_exit, regsize = 64
>         adr     x30, tramp_vectors
>         msr     vbar_el1, x30
>         tramp_unmap_kernel      x30
>         .if     \regsize == 64
>         mrs     x30, far_el1
>         .endif
>         eret
>         .endm
> 
> ENTRY(tramp_exit_native)
>         tramp_exit
> END(tramp_exit_native)
> 
> ENTRY(tramp_exit_compat)
>         tramp_exit      32
> END(tramp_exit_compat)
> 
> 
> One approach I would consider for this is to duplicate this
> comment and add it just above the "eret" instruction within the
> macro:
> 
> 	/*
> 	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
> 	 * when returning from IPI handler, and when returning to user-space.
> 	 */
> 
> Or perhaps Will has something else in mind ?

To be honest with you, I'd just drop the comment entirely. entry.S is
terrifying these days and nobody should have to go in there to understand
why we select ARCH_HAS_MEMBARRIER_SYNC_CORE. If you really feel a justification
is needed, I'd be happy with a line in the Kconfig file.

Will