linux-kernel - [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc

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

Date:   Mon, 29 May 2017 18:32:00 +0200
From:   David Hildenbrand <david@...hat.com>
To:     kvm@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Thomas Huth <thuth@...hat.com>, david@...hat.com,
        Christian Borntraeger <borntraeger@...ibm.com>
Subject: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

Having to enable vm.alloc_pgste globally might not be the best solution.
4k page tables are created for all processes and running QEMU KVM guests
is more complicated than it should be.

Unfortunately, converting all page tables to 4k pgste page tables is
not possible without provoking various race conditions. However, we
might be able to let 2k and 4k page tables co-exist. We only need
4k page tables whenever we want to expose such memory to a guest. So
turning on 4k page table allocation at one point and only allowing such
memory to go into our gmap (guest mapping) might be a solution.

User space tools like QEMU that create the VM before mmap-ing any memory
that will belong to the guest can simply use the new VM type. Proper 4k
page tables will be created for any memory mmap-ed afterwards. And these
can be used in the gmap without problems. Existing user space tools
will work as before - having to enable vm.alloc_pgste explicitly.

This should play fine with vSIE, as vSIE code works completely on the gmap.
So if only page tables with pgste go into our gmap, we should be fine.

Not sure if this breaks important concepts, has some serious performance
problems or I am missing important cases. If so, I guess there is really
no way to avoid setting vm.alloc_pgste.

Possible modifications:
- Enable this option via an ioctl (like KVM_S390_ENABLE_SIE) instead of
  a new VM type
- Remember if we have mixed pgtables. If !mixed, we can make maybe faster
  decisions (if that is really a problem).

Only very quickly tested under KVM on z/VM. Will do some more testing if
this idea is worth working on.
Based on linux-next.git/master

David Hildenbrand (2):
  s390x: mm: allow mixed page table types (2k and 4k)
  KVM: s390: Introduce KVM_VM_S390_LATE_MMAP

 Documentation/virtual/kvm/api.txt | 13 +++++++++
 arch/s390/include/asm/pgtable.h   | 15 ++++++++--
 arch/s390/kvm/kvm-s390.c          | 10 +++++--
 arch/s390/mm/gmap.c               | 11 ++++++--
 arch/s390/mm/pgalloc.c            | 14 ++++++----
 arch/s390/mm/pgtable.c            | 59 +++++++++++++++++++++++++++++++++------
 include/uapi/linux/kvm.h          |  2 ++
 7 files changed, 101 insertions(+), 23 deletions(-)

-- 
2.9.3