lkml.org 
[lkml]   [2023]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Date
    SubjectRe: [PATCH v2 1/2] x86/speculation: Allow enabling STIBP with legacy IBRS
    On Tue, Feb 21, 2023 at 7:07 PM Pawan Gupta
    <pawan.kumar.gupta@linux.intel.com> wrote:
    >
    > On Tue, Feb 21, 2023 at 07:49:07PM +0100, KP Singh wrote:
    > > Setting the IBRS bit implicitly enables STIBP to protect against
    > > cross-thread branch target injection. With enhanced IBRS, the bit it set
    > > once and is not cleared again. However, on CPUs with just legacy IBRS,
    > > IBRS bit set on user -> kernel and cleared on kernel -> user (a.k.a
    > > KERNEL_IBRS). Clearing this bit also disables the implicitly enabled
    > > STIBP, thus requiring some form of cross-thread protection in userspace.
    > >
    > > Enable STIBP, either opt-in via prctl or seccomp, or always on depending
    > > on the choice of mitigation selected via spectre_v2_user.
    > >
    > > Reported-by: José Oliveira <joseloliveira11@gmail.com>
    > > Reported-by: Rodrigo Branco <rodrigo@kernelhacking.com>
    > > Reviewed-by: Alexandra Sandulescu <aesa@google.com>
    > > Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
    > > Cc: stable@vger.kernel.org
    > > Signed-off-by: KP Singh <kpsingh@kernel.org>
    > > ---
    > > arch/x86/kernel/cpu/bugs.c | 33 ++++++++++++++++++++++-----------
    > > 1 file changed, 22 insertions(+), 11 deletions(-)
    > >
    > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
    > > index 85168740f76a..5be6075d8e36 100644
    > > --- a/arch/x86/kernel/cpu/bugs.c
    > > +++ b/arch/x86/kernel/cpu/bugs.c
    > > @@ -1124,14 +1124,30 @@ spectre_v2_parse_user_cmdline(void)
    > > return SPECTRE_V2_USER_CMD_AUTO;
    > > }
    > >
    > > -static inline bool spectre_v2_in_ibrs_mode(enum spectre_v2_mitigation mode)
    > > +static inline bool spectre_v2_in_eibrs_mode(enum spectre_v2_mitigation mode)
    > > {
    > > - return mode == SPECTRE_V2_IBRS ||
    > > - mode == SPECTRE_V2_EIBRS ||
    > > + return mode == SPECTRE_V2_EIBRS ||
    > > mode == SPECTRE_V2_EIBRS_RETPOLINE ||
    > > mode == SPECTRE_V2_EIBRS_LFENCE;
    > > }
    > >
    > > +static inline bool spectre_v2_in_ibrs_mode(enum spectre_v2_mitigation mode)
    > > +{
    > > + return spectre_v2_in_eibrs_mode(mode) || mode == SPECTRE_V2_IBRS;
    > > +}
    > > +
    > > +static inline bool spectre_v2_user_needs_stibp(enum spectre_v2_mitigation mode)
    > > +{
    > > + /*
    > > + * enhanced IBRS also protects against user-mode attacks as the IBRS bit
    >
    > Maybe:
    > * Enhanced IBRS mode also protects against cross-thread user-to-user
    > * attacks as the IBRS bit

    updated, thanks!

    >
    > > + * remains always set which implicitly enables cross-thread protections.
    > > + * However, In legacy IBRS mode, the IBRS bit is set only in kernel
    > > + * and cleared on return to userspace. This disables the implicit
    > > + * cross-thread protections and STIBP is needed.
    > > + */
    > > + return !spectre_v2_in_eibrs_mode(mode);
    > > +}
    > > +
    > > static void __init
    > > spectre_v2_user_select_mitigation(void)
    > > {
    > > @@ -1193,13 +1209,8 @@ spectre_v2_user_select_mitigation(void)
    > > "always-on" : "conditional");
    > > }
    > >
    > > - /*
    > > - * If no STIBP, IBRS or enhanced IBRS is enabled, or SMT impossible,
    > > - * STIBP is not required.
    > > - */
    > > - if (!boot_cpu_has(X86_FEATURE_STIBP) ||
    > > - !smt_possible ||
    > > - spectre_v2_in_ibrs_mode(spectre_v2_enabled))
    > > + if (!boot_cpu_has(X86_FEATURE_STIBP) || !smt_possible ||
    > > + !spectre_v2_user_needs_stibp(spectre_v2_enabled))
    >
    > As pointed out in other discussions, it will be great if can get rid of
    > eIBRS check, and do what the user asked for; or atleast print a warning

    I think I will keep it as pr_info as, with eIBRS, the user does not
    really need STIBP and the mitigation is still effective.

    > about not setting STIBP bit explicitly.

    That is a bit more complicated as, for now, the user is not really
    exposed to STIBP explicitly yet.

    { "auto", SPECTRE_V2_USER_CMD_AUTO, false },
    { "off", SPECTRE_V2_USER_CMD_NONE, false },
    { "on", SPECTRE_V2_USER_CMD_FORCE, true },
    { "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
    { "prctl,ibpb", SPECTRE_V2_USER_CMD_PRCTL_IBPB, false },
    { "seccomp", SPECTRE_V2_USER_CMD_SECCOMP, false },
    { "seccomp,ibpb", SPECTRE_V2_USER_CMD_SECCOMP_IBPB, false },

    I would prefer to do it as a follow up and fix this bug first.

    It's a bit gnarly and I think we really need to think about the
    options that are exposed to the user [especially in light of Intel /
    AMD subtelties].

    With the current patch the userspace is still getting working V2
    mitigations on both dimensions time (Process A followed by Process B
    where A does BTI on the subsequent B that are flushed via an IBPB) and
    space (i.e. cross-thread branch target injection) whenever necessary.




    >
    > > return;
    > >
    > > /*
    > > @@ -2327,7 +2338,7 @@ static ssize_t mmio_stale_data_show_state(char *buf)
    > >
    > > static char *stibp_state(void)
    > > {
    > > - if (spectre_v2_in_ibrs_mode(spectre_v2_enabled))
    > > + if (!spectre_v2_user_needs_stibp(spectre_v2_enabled))
    >
    > Decoupling STIBP and eIBRS will also get rid of this check.
    >
    > > return "";

    \
     
     \ /
      Last update: 2023-03-27 00:32    [W:5.175 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site