linux-kernel - [RFC RESEND PATCH 0/6] Process-local memory allocations

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Nov 2018 17:49:33 +0100
From:   Julian Stecklina <jsteckli@...zon.de>
To:     kernel-hardening@...ts.openwall.com
Cc:     Julian Stecklina <jsteckli@...zon.de>,
        Liran Alon <liran.alon@...cle.com>,
        Tycho Andersen <tycho@...ho.ws>,
        Jonathan Adams <jwadams@...gle.com>,
        David Woodhouse <dwmw2@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: [RFC RESEND PATCH 0/6] Process-local memory allocations

In a world with processor information leak vulnerabilities, having a treasure
trove of information available for leaking in the global kernel address space is
starting to be a liability. The biggest offender is the linear mapping of all
physical memory and there are already efforts (XPFO) to start addressing this.
In this patch series, I'd like to propose breaking up the kernel address space
further and introduce process-local mappings in the kernel.

The rationale is that there are allocations in the kernel containing data that
should only be accessible when the kernel is executing in the context of a
specific process. A prime example is KVM vCPU state. This patch series
introduces process-local memory in the kernel address space by claiming a PGD
entry for this specific purpose. Then it converts KVM on x86 to use these new
primitives to store GPR and FPU registers of vCPUs. KVM is a good testing
ground, because it makes sure userspace can only interact with a VM from a
single process.

Process-local allocations in the kernel can be part of a robust L1TF mitigation
strategy that works even with SMT enabled. The specific goal here is to make it
harder for a random thread using cache load gadget (usually a bounds check of a
system call argument plus array access suffices) to prefetch interesting data
into the L1 cache and use L1TF to leak this data.

The patch set applies to kvm/next [1]. Feedback is very welcome, both about the
general approach and the actual implementation. As far as testing goes, the KVM
unit tests seem happy on Intel. AMD is only compile tested at the moment.

[1] git://git.kernel.org/pub/scm/virt/kvm/kvm.git

Julian Stecklina (6):
  kvm, vmx: move CR2 context switch out of assembly path
  kvm, vmx: move register clearing out of assembly path
  mm, x86: make __kernel_map_pages always available
  x86/speculation, mm: add process local virtual memory region
  x86/speculation, kvm: move guest FPU state into process local memory
  x86/speculation, kvm: move gprs to process local storage

 arch/x86/Kconfig                        |   1 +
 arch/x86/include/asm/kvm_host.h         |  13 +-
 arch/x86/include/asm/pgtable_64_types.h |   6 +
 arch/x86/include/asm/proclocal.h        |  44 ++++
 arch/x86/kvm/kvm_cache_regs.h           |   4 +-
 arch/x86/kvm/svm.c                      | 132 +++++++-----
 arch/x86/kvm/vmx.c                      | 203 ++++++++++--------
 arch/x86/kvm/x86.c                      |  45 ++--
 arch/x86/mm/Makefile                    |   2 +
 arch/x86/mm/dump_pagetables.c           |   3 +
 arch/x86/mm/fault.c                     |  14 ++
 arch/x86/mm/pageattr.c                  |   3 +-
 arch/x86/mm/proclocal.c                 | 269 ++++++++++++++++++++++++
 include/linux/mm.h                      |   3 +-
 include/linux/mm_types.h                |   7 +
 security/Kconfig                        |  16 ++
 16 files changed, 596 insertions(+), 169 deletions(-)
 create mode 100644 arch/x86/include/asm/proclocal.h
 create mode 100644 arch/x86/mm/proclocal.c

-- 
2.17.1