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, 14 Feb 2018 10:31:36 -0500
From:   James Y Knight <jyknight@...gle.com>
To:     "Yatsina, Marina" <marina.yatsina@...el.com>
Cc:     Kees Cook <keescook@...gle.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Chandler Carruth <chandlerc@...gle.com>,
        "Kreitzer, David L" <david.l.kreitzer@...el.com>,
        "Grischenko, Andrei L" <andrei.l.grischenko@...el.com>,
        "rnk@...gle.com" <rnk@...gle.com>,
        LLVM Developers <llvm-dev@...ts.llvm.org>,
        "ehsan@...illa.com" <ehsan@...illa.com>,
        "Tayree, Coby" <coby.tayree@...el.com>,
        Matthias Braun <matze@...unis.de>,
        Dean Michael Berris <dean.berris@...il.com>,
        Guenter Roeck <linux@...ck-us.net>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Rik van Riel <riel@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jiri Kosina <jikos@...nel.org>,
        Andy Lutomirski <luto@...capital.net>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
        Paul Turner <pjt@...gle.com>,
        Stephen Hines <srhines@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add
 clang support)

I'd be definitely in favor having clang support asm goto. I wouldn't
want to exclude having other conversations about how to more directly
provide compiler features that the linux kernel could use, ALSO, but I
do not think that conversation should block implementing asm-goto.

IMO, inline asm is, generally, a valuable feature to provide in the
compiler as an escape hatch, and asm goto is a relatively sane
extension of it. Supporting outgoing edges from an inline asm block is
a reasonable thing for users to desire, and as far as anyone's said so
far, seems like it ought to be fairly easily implementable, without
causing bad side-effects in the compiler.

Of course, we generally do want to minimize the need for users to use
inline asm, by providing appropriate compiler support for the features
people would otherwise be forced to implement using asm. But I don't
see that as really any more important for asm-goto than any other
inline asm. There will always be a desire for escape hatches, to do
weird and unique things which aren't supported directly in the
compiler. (Also, the kernel is a pretty special case in terms of its
requirements, it seems exceedingly unlikely that we could ever provide
enough compiler support to let it eliminate inline asm.).

On Wed, Feb 14, 2018 at 3:33 AM, Yatsina, Marina
<marina.yatsina@...el.com> wrote:
>
> Hi Kees,
>
> When I raised the question of whether we want to add support for "asm goto" in llvm I got some feedback from the community that "asm goto" might not be the best solution for the problem it was invented for (optimizing support for tracepoints), so I stopped perusing this issue.
> I'm CC-ing the developers that participated in the original thread and a few developers that might be interested in adding support of "asm goto".
> I'm also adding the llvm-dev mailing list, in case there are additional parties interested in voicing their opinion.
>
> I hope this will give this issue a push forward and we will find a solution that will not prevent llvm from compiling linux kernel.
>
> Thanks,
> Marina
>
> -----Original Message-----
> From: Kees Cook [mailto:keescook@...gle.com]
> Sent: Wednesday, February 14, 2018 02:29
> To: David Woodhouse <dwmw2@...radead.org>; Chandler Carruth <chandlerc@...gle.com>; Yatsina, Marina <marina.yatsina@...el.com>
> Cc: Guenter Roeck <linux@...ck-us.net>; X86 ML <x86@...nel.org>; LKML <linux-kernel@...r.kernel.org>; Alan Cox <gnomes@...rguk.ukuu.org.uk>; Rik van Riel <riel@...hat.com>; Andi Kleen <ak@...ux.intel.com>; Josh Poimboeuf <jpoimboe@...hat.com>; Tom Lendacky <thomas.lendacky@....com>; Peter Zijlstra <peterz@...radead.org>; Linus Torvalds <torvalds@...ux-foundation.org>; Jiri Kosina <jikos@...nel.org>; Andy Lutomirski <luto@...capital.net>; Hansen, Dave <dave.hansen@...el.com>; Tim Chen <tim.c.chen@...ux.intel.com>; Greg Kroah-Hartman <gregkh@...ux-foundation.org>; Paul Turner <pjt@...gle.com>; Stephen Hines <srhines@...gle.com>; Nick Desaulniers <ndesaulniers@...gle.com>
> Subject: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)
>
> On Tue, Feb 13, 2018 at 4:10 PM, David Woodhouse <dwmw2@...radead.org> wrote:
> > We also need to resolve the asm-goto thing.
>
> Yes, this is becoming much more urgent, assuming we'll be raising the minimum GCC version soon and drop support for lacking asm-goto...
>
> Do you happen to know who the right people are to include to move the discussion forward? I know various kernel folks that are passionate about it, but I'm still getting to know who to talk with from llvm.
>
> I see an earlier thread here:
> http://lists.llvm.org/pipermail/llvm-dev/2017-April/111748.html
>
> It seems to end there? I'm still coming up to speed on it, so I'm likely missing other context.
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ