linux-kernel - Re: [PATCH v6 3/3] x86: paravirt: make native_save

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]

Message-ID: <20180626071325.GA25751@gmail.com>
Date:   Tue, 26 Jun 2018 09:13:25 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     mingo@...hat.com, Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>, hpa@...or.com,
        linux-efi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        x86@...nel.org, virtualization@...ts.linux-foundation.org,
        Alistair Strachan <astrachan@...gle.com>,
        Manoj Gupta <manojgupta@...gle.com>,
        Greg Hackmann <ghackmann@...gle.com>, sedat.dilek@...il.com,
        tstellar@...hat.com, Kees Cook <keescook@...gle.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        geert@...ux-m68k.org, Will Deacon <will.deacon@....com>,
        mawilcox@...rosoft.com, Arnd Bergmann <arnd@...db.de>,
        David Rientjes <rientjes@...gle.com>, acme@...hat.com,
        Philippe Ombredanne <pombredanne@...b.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        boris.ostrovsky@...cle.com, "J. Kiszka" <jan.kiszka@...mens.com>,
        rostedt@...dmis.org, kirill.shutemov@...ux.intel.com,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        akataria@...are.com, brijesh.singh@....com,
        Cao jin <caoj.fnst@...fujitsu.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        jarkko.sakkinen@...ux.intel.com, jgross@...e.com,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Matthias Kaehlcke <mka@...omium.org>, thomas.lendacky@....com,
        Thiebaud Weksteen <tweek@...gle.com>, mjg59@...gle.com,
        joe@...ches.com, andrea.parri@...rulasolutions.com
Subject: Re: [PATCH v6 3/3] x86: paravirt: make native_save_fl extern inline


* Nick Desaulniers <ndesaulniers@...gle.com> wrote:

> On Thu, Jun 21, 2018 at 7:24 PM Ingo Molnar <mingo@...nel.org> wrote:
> > * Nick Desaulniers <ndesaulniers@...gle.com> wrote:
> >
> > > native_save_fl() is marked static inline, but by using it as
> > > a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
> >
> > > --- a/arch/x86/include/asm/irqflags.h
> > > +++ b/arch/x86/include/asm/irqflags.h
> > > @@ -13,7 +13,7 @@
> > >   * Interrupt control:
> > >   */
> > >
> > > -static inline unsigned long native_save_fl(void)
> > > +extern inline unsigned long native_save_fl(void)
> > >  {
> > >       unsigned long flags;
> > >
> >
> > What's the code generation effect of this on say a defconfig kernel vmlinux with
> > paravirt enabled?
> 
> Starting with this patch set applied:
> $ make CC=gcc-8 -j46
> $ objdump -d vmlinux | grep native_save_fl --context=3
> ffffffff81059140 <native_save_fl>:
> ffffffff81059140: 9c                    pushfq
> ffffffff81059141: 58                    pop    %rax
> ffffffff81059142: c3                    retq
> $ git checkout HEAD~3
> $ make CC=gcc-8 -j46
> $ objdump -d vmlinux | grep native_save_fl --context=3
> ffffffff81079410 <native_save_fl>:
> ffffffff81079410: 9c                    pushfq
> ffffffff81079411: 58                    pop    %rax
> ffffffff81079412: c3                    retq
> 
> Mainly, this is to prevent the compiler from adding a stack protector
> to the outlined version, as the stack protector clobbers %rcx, but
> paravirt expects %rcx to be preserved. More info can be found:
> https://lkml.org/lkml/2018/5/24/1242--

Ok!

Acked-by: Ingo Molnar <mingo@...nel.org>

What's the planned upstreaming route for these patches/fixes?

Thanks,

	Ingo