linux-kernel - Re: [RFC PATCH v2 1/2] x86/speculation: Allow per-process control of when to issue IBPB

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] [day] [month] [year] [list]

Message-ID: <CAATStaOmBw1nr9Y5pZw9MXK0Y4TMvyOe0M6-PZpy7RQnS0szyA@mail.gmail.com>
Date:   Tue, 11 May 2021 18:39:15 +1000
From:   "Anand K. Mistry" <amistry@...gle.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     x86@...nel.org, Joel Fernandes <joelaf@...gle.com>,
        Anthony Steinhauser <asteinhauser@...gle.com>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Ben Segall <bsegall@...gle.com>,
        Catalin Marinas <catalin.marinas@....com>,
        "Chang S. Bae" <chang.seok.bae@...el.com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Gabriel Krisman Bertazi <krisman@...labora.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Jay Lang <jaytlang@....edu>, Jens Axboe <axboe@...nel.dk>,
        Juri Lelli <juri.lelli@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Lai Jiangshan <laijs@...ux.alibaba.com>,
        Mel Gorman <mgorman@...e.de>, Mike Rapoport <rppt@...nel.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Peter Collingbourne <pcc@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Tony Luck <tony.luck@...el.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 1/2] x86/speculation: Allow per-process control of
 when to issue IBPB

On Mon, 3 May 2021 at 18:48, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> Anand,
>
> On Thu, Apr 29 2021 at 18:44, Anand K. Mistry wrote:
> >
> > -static inline unsigned long mm_mangle_tif_spec_ib(struct task_struct *next)
> > +static inline unsigned long mm_mangle_tif_spec_ib_on_leave(
> > +     struct task_struct *next)
> >  {
> >       unsigned long next_tif = task_thread_info(next)->flags;
> > -     unsigned long ibpb = (next_tif >> TIF_SPEC_IB) & LAST_USER_MM_IBPB;
> > +     unsigned long spec_disabled =
> > +             (next_tif >> TIF_SPEC_IB) & ~(next_tif >> TIF_NO_IBPB_LEAVE);
> > +     unsigned long ibpb = spec_disabled & LAST_USER_MM_IBPB;
> >
> >       return (unsigned long)next->mm | ibpb;
> >  }
> >
> > +static inline bool ibpb_on_entry(struct task_struct *next)
> > +{
> > +     unsigned long next_tif = task_thread_info(next)->flags;
> > +     unsigned long spec_disabled =
> > +             (next_tif >> TIF_SPEC_IB) & ~(next_tif >> TIF_NO_IBPB_ENTRY);
> > +     return spec_disabled & 1;
> > +}
>
> Why exactly do we need _three_ TIF bits and this non-intuitive inverted
> logic?

The inverted logic is to avoid any side effects of flag bits
defaulting to 0, which should keep the existing behaviour of doing an
IBPB on both entry and exit.

>
> The existing mode is: Issue IBPB when scheduling in and when scheduling out.
>
> Ergo the obvious approach for making it more finegrained is to split the
> existing TIF_SPEC_IB into TIF_SPEC_IB_IN and TIF_SPEC_IB_OUT and have
> the existing mode both bits set.

Agreed. The problem is the existing bit doesn't just control IBPB
behaviour. It also controls STIBP, which you can kinda control
separately on the command line when booting with the spectre_v2_user
flag. The code, however, uses the same flag for both (see
arch/x86/include/asm/spec-ctrl.h).

Maybe this is another cleanup I should do prior to this change?
Separating IBPB and STIBP flags in the implementation.

>
> Thanks,
>
>         tglx
>
>