Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230809071218.000335006@infradead.org> <20230809072200.543939260@infradead.org>
 <20230810115148.GEZNTPVLBmPL6uz4Af@fat_crate.local> <20230810123756.GY212435@hirez.programming.kicks-ass.net>
 <20230811070123.GD220434@hirez.programming.kicks-ass.net>
In-Reply-To: <20230811070123.GD220434@hirez.programming.kicks-ass.net>
From:   Nick Desaulniers <ndesaulniers@google.com>
Date:   Fri, 11 Aug 2023 10:00:31 -0700
Message-ID: <CAKwvOd=UXhDShdPsofrWScxdF-mTNnDTCNYZDP1rAhhKCB7jVA@mail.gmail.com>
Subject: Re: [RFC][PATCH 02/17] x86/cpu: Clean up SRSO return thunk mess
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Borislav Petkov <bp@alien8.de>, x86@kernel.org,
        linux-kernel@vger.kernel.org, David.Kaplan@amd.com,
        Andrew.Cooper3@citrix.com, jpoimboe@kernel.org,
        gregkh@linuxfoundation.org, matz@suse.de, joao.moreira@intel.com,
        samitolvanen@google.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Aug 11, 2023 at 12:01=E2=80=AFAM Peter Zijlstra <peterz@infradead.o=
rg> wrote:
>
> On Thu, Aug 10, 2023 at 02:37:56PM +0200, Peter Zijlstra wrote:
>
> > After this patch things look equivalent to:
> >
> > SYM_FUNC_START(foo)
> >       ...
> >       ALTERNATIVE "ret; int3"
> >                   "jmp __x86_return_thunk", X86_FEATURE_RETHUNK
> >                   "jmp srso_return_thunk, X86_FEATURE_SRSO
> >                   "jmp srsi_alias_return_thunk", X86_FEATURE_SRSO_ALIAS
> > SYM_FUNC_END(foo)
> >
> > SYM_CODE_START(srso_return_thunk)
> >       UNWIND_HINT_FUNC
> >       ANNOTATE_NOENDBR
> >       call srso_safe_ret;
> >       ud2
> > SYM_CODE_END(srso_return_thunk)
> >
> > SYM_CODE_START(srso_alias_return_thunk)
> >       UNWIND_HINT_FUNC
> >       ANNOTATE_NOENDBR
> >       call srso_alias_safe_ret;
> >       ud2
> > SYM_CODE_END(srso_alias_return_thunk)
> >
>
> So it looks like the compilers are still not emitting int3 after jmp,
> even with the SLS options enabled :/
>
> This means the tail end of functions compiled with:
>
>   -mharden-sls=3Dall -mfunction-return=3Dthunk-extern
>
> Is still a regular: jmp __x86_return_thunk, no trailing trap.
>
>   https://godbolt.org/z/Ecqv76YbE

I don't have time to finish this today, but
https://reviews.llvm.org/D157734 should do what you're looking for, I
think.

>
> If we all could please finally fix that, then I can rewrite the above to
> effectively be:
>
> SYM_FUNC_START(foo)
>         ...
>         ALTERNATIVE "ret; int3"
>                     "jmp __x86_return_thunk", X86_FEATURE_RETHUNK
>                     "call srso_safe_ret, X86_FEATURE_SRSO
>                     "call srso_alias_safe_ret", X86_FEATURE_SRSO_ALIAS
>         int3 //  <--- *MISSING*
> SYM_FUNC_END(foo)
>
> Bonus points if I can compile time tell if a compiler DTRT, feature flag
> or what have you in the preprocessor would be awesome.

Probably not a preprocessor token; in the past I have made that
suggestion and the old guard informed me "no, too many preprocessor
tokens to lex, no more!"  I still disagree but that is a viewpoint I
can sympathize with, slightly.

Probably version checks for now on the SLS config (or version checks
on a new kconfig CONFIG_IMPROVED_SLS)

--=20
Thanks,
~Nick Desaulniers