linux-kernel - Re: [PATCH v4 0/5] Next revision of the L1D flush patches

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]
Message-ID: <cf89f0389379daaaff0cbce9c5f1550866e55e91.camel@amazon.com>
Date:   Mon, 25 Jan 2021 09:27:38 +0000
From:   "Singh, Balbir" <sblbir@...zon.com>
To:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>
Subject: Re: [PATCH v4 0/5] Next revision of the L1D flush patches

On Fri, 2021-01-08 at 23:10 +1100, Balbir Singh wrote:
> Implement a mechanism that allows tasks to conditionally flush
> their L1D cache (mitigation mechanism suggested in [2]). The previous
> posts of these patches were sent for inclusion (see [3]) and were not
> included due to the concern for the need for additional checks,
> those checks were:
> 
> 1. Implement this mechanism only for CPUs affected by the L1TF bug
> 2. Disable the software fallback
> 3. Provide an override to enable this mechanism
> 4. Be SMT aware in the implementation
> 
> The patches support a use case where the entire system is not in
> non SMT mode, but rather a few CPUs can have their SMT turned off
> and processes that want to opt-in are expected to run on non SMT
> cores. This gives the administrator complete control over setting
> up the mitigation for the issue. In addition, the administrator
> has a boot time override (l1d_flush=on) to turn on the mechanism
> without which this mechanism will not work.
> 
> To implement these efficiently, a new per cpu view of whether the core
> is in SMT mode or not is implemented in patch 1. The code is refactored
> in patch 2 so that the existing code can allow for other speculation
> related checks when switching mm between tasks, this mechanism has not
> changed since the last post. The ability to flush L1D for tasks if the
> TIF_SPEC_L1D_FLUSH bit is set and the task has context switched out of a
> non SMT core is provided by patch 3. Hooks for the user space API, for
> this feature to be invoked via prctl are provided in patch 4, along with
> the checks described above (1, 2, and 3). Documentation updates are in
> patch 5, with updates on l1d_flush, the prctl changes and updates to the
> kernel-parameters (l1d_flush_out).
> 
> The checks for opting into L1D flushing are:
> 	a. If the CPU is affected by L1TF
>         b. Hardware L1D flush mechanism is available
> 
> A task running on a core with SMT enabled and opting into this feature will
> receive a SIGBUS.
> 
> References
> [1] https://software.intel.com/security-software-guidance/software-guidance/snoop-assisted-l1-data-sampling
> [2] https://software.intel.com/security-software-guidance/insights/deep-dive-snoop-assisted-l1-data-sampling
> [3] https://lkml.org/lkml/2020/6/2/1150
> [4] https://lore.kernel.org/lkml/20200729001103.6450-1-sblbir@amazon.com/
> [5] https://lore.kernel.org/lkml/20201117234934.25985-2-sblbir@amazon.com/
> 
> Reviewers guide to v4
> - The key patch in the series and most of the changes to this
>   revision are to patch 4. patches 3 and 5 have been modified
>   to keep them consistent with the changes to patch 4.
> 
> Changelog v4:
> - Use a static key to enable the mechanism (remove overheads)
> - By default have the mechanism turned off, so there are two
>   opt-ins needed, one by the administrator at boot time, second
>   by the application
> - Rename l1d_flush_out/L1D_FLUSH_OUT to l1d_flush/L1D_FLUSH
> - Implement other review recommendations
> Changelog v3:
> - Implement the SIGBUS mechansim
> - Update and fix the documentation
> 
> 
> Balbir Singh (5):
>   x86/smp: Add a per-cpu view of SMT state
>   x86/mm: Refactor cond_ibpb() to support other use cases
>   x86/mm: Optionally flush L1D on context switch
>   prctl: Hook L1D flushing in via prctl
>   Documentation: Add L1D flushing Documentation
> 
>  Documentation/admin-guide/hw-vuln/index.rst   |  1 +
>  .../admin-guide/hw-vuln/l1d_flush.rst         | 70 +++++++++++++++
>  .../admin-guide/kernel-parameters.txt         | 17 ++++
>  Documentation/userspace-api/spec_ctrl.rst     |  8 ++
>  arch/Kconfig                                  |  4 +
>  arch/x86/Kconfig                              |  1 +
>  arch/x86/include/asm/cacheflush.h             |  8 ++
>  arch/x86/include/asm/nospec-branch.h          |  2 +
>  arch/x86/include/asm/processor.h              |  2 +
>  arch/x86/include/asm/thread_info.h            |  6 +-
>  arch/x86/include/asm/tlbflush.h               |  2 +-
>  arch/x86/kernel/cpu/bugs.c                    | 71 +++++++++++++++
>  arch/x86/kernel/smpboot.c                     | 10 ++-
>  arch/x86/mm/tlb.c                             | 88 ++++++++++++++-----
>  include/linux/sched.h                         | 10 +++
>  include/uapi/linux/prctl.h                    |  1 +
>  16 files changed, 273 insertions(+), 28 deletions(-)
>  create mode 100644 Documentation/admin-guide/hw-vuln/l1d_flush.rst
>

Ping on any review comments? Suggested refactoring?

Balbir Singh