llvm dev - Feb 2018 - retpoline mitigation and 6.0

Hi all,

I saw the retpoline mitigation landed in r323155. Are we ready to merge
this to 6.0, or are there any open issues that we're waiting for? Also,
were there any followups I should know about? Also, release notes please :-)

Thanks,
Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180201/b9be1390/attachment.html>

There was one open issue that i landed the fix for today.

I was letting bots clear out before i ping you with the patch series to
merge.

On Thu, Feb 1, 2018 at 1:11 AM Hans Wennborg <hans at chromium.org> wrote:
> Hi all,
>
> I saw the retpoline mitigation landed in r323155. Are we ready to merge
> this to 6.0, or are there any open issues that we're waiting for? Also,
> were there any followups I should know about? Also, release notes please
:-)
>
> Thanks,
> Hans
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180201/310a5e46/attachment.html>

Sounds great, thanks!

On Thu, Feb 1, 2018 at 10:16 AM, Chandler Carruth <chandlerc at
google.com>
wrote:
> There was one open issue that i landed the fix for today.
>
> I was letting bots clear out before i ping you with the patch series to
> merge.
>
> On Thu, Feb 1, 2018 at 1:11 AM Hans Wennborg <hans at chromium.org>
wrote:
>
>> Hi all,
>>
>> I saw the retpoline mitigation landed in r323155. Are we ready to merge
>> this to 6.0, or are there any open issues that we're waiting for?
Also,
>> were there any followups I should know about? Also, release notes
please :-)
>>
>> Thanks,
>> Hans
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180201/de39c367/attachment-0001.html>

On 02/01/2018 01:10 AM, Hans Wennborg via llvm-dev
wrote:
> Hi all,
> 
> I saw the retpoline mitigation landed in r323155. Are we ready to merge
this to 6.0, or are there any open issues that we're waiting for? Also, were
there any followups I should know about? Also, release notes please :-)
> 
There was a follow up commit for lld: r323288

-Tom
> Thanks,
> Hans
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev
wrote:
> 
> I saw the retpoline mitigation landed in r323155. Are we ready to
> merge this to 6.0, or are there any open issues that we're waiting
> for? Also, were there any followups I should know about? Also,
> release notes please :-)
Eep, please can we keep the command line option for clang and the thunk
ABI matching what GCC, the Linux kernel and Xen are all doing?

To say that I am not stunningly keen on
https://lkml.org/lkml/2018/2/2/975 would be a bit of an
understatement...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180203/1cfad99e/attachment.bin>

On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org>
wrote:
> On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote:
> >
> > I saw the retpoline mitigation landed in r323155. Are we ready to
> > merge this to 6.0, or are there any open issues that we're waiting
> > for? Also, were there any followups I should know about? Also,
> > release notes please :-)
>
> Eep, please can we keep the command line option for clang and the thunk
> ABI matching what GCC, the Linux kernel and Xen are all doing?
>
> To say that I am not stunningly keen on
> https://lkml.org/lkml/2018/2/2/975 would be a bit of an
> understatement...

Two aspects to this...

One, we're somewhat reluctant to guarantee an ABI here. At least I am.
While we don't *expect* rampant divergence here, I don't want this to
become something we cannot change if there are good reasons to do so. We've
already changed the thunks once based on feedback (putting LFENCE after the
PAUSE).

Given that we don't want this to be a guaranteed part of the ABI, I really
want the thunk names to be specific about which implementation is being
used. For example, if we come up with a new, better thunk interface, we
would want to give it a new name (even if it were just a suffix of
"2") so
that we don't get runtime failures. Since LLVM and GCC can't possible
release in sync, IMO they *should* use different names. I asked the GCC
developers to include 'gcc' in the name, but at least the person I asked
was not at all receptive.


Two, I actually agree with you about the command line flags. I asked for it
to be '-mretpoline'. I think a short, clear flag is really best, and
we've
very publicly documented this technique as 'retpoline'. But the GCC
community has a fairly different design AFAICT... The only embedded thunks
the offer are inline (ours are always out-of-line, even if they aren't
external). Also, they support thunking indirect branches that we don't:
ret. Our feature really is oriented around exposing the retpoline
mitigation, and I don't think there is any demand for the complexity that
would be entailed by generalizing it further. But I'm sure the GCC folks
have a very reasonably different perspective here that make them prefer a
quite different feature (they can thunk rets) and naming scheme.


So I don't really know how to fix this. I think there are reasonable
arguments in each direction. IMO, the easiest improvement would be for GCC
to add command line aliases spelled using 'retpoline' for the specific
use
case, but keep the more general commandline interface for which they have
reasonable use cases.

The naming thing I think is essentially by-design so that if we (or you)
need to split apart the implementation, there are distinct names available.
Until then, aliases seem very cheap to maintain?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180203/223d1983/attachment.html>