linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org,
	linux-mm@kvack.org, David Hildenbrand <david@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Subject: [PATCH resend RFC 0/9] s390: fixes, cleanups and optimizations for page table walkers
Date: Thu,  9 Sep 2021 18:22:39 +0200	[thread overview]
Message-ID: <20210909162248.14969-1-david@redhat.com> (raw)

Resend because I missed ccing people on the actual patches ...

RFC because the patches are essentially untested and I did not actually
try to trigger any of the things these patches are supposed to fix. It
merely matches my current understanding (and what other code does :) ). I
did compile-test as far as possible.

After learning more about the wonderful world of page tables and their
interaction with the mmap_sem and VMAs, I spotted some issues in our
page table walkers that allow user space to trigger nasty behavior when
playing dirty tricks with munmap() or mmap() of hugetlb. While some issues
should be hard to trigger, others are fairly easy because we provide
conventient interfaces (e.g., KVM_S390_GET_SKEYS and KVM_S390_SET_SKEYS).

Future work:
- Don't use get_locked_pte() when it's not required to actually allocate
  page tables -- similar to how storage keys are now handled. Examples are
  get_pgste() and __gmap_zap.
- Don't use get_locked_pte() and instead let page fault logic allocate page
  tables when we actually do need page tables -- also, similar to how
  storage keys are now handled. Examples are set_pgste_bits() and
  pgste_perform_essa().
- Maybe switch to mm/pagewalk.c to avoid custom page table walkers. For
  __gmap_zap() that's very easy.

Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Janosch Frank <frankja@linux.ibm.com>
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>

David Hildenbrand (9):
  s390/gmap: validate VMA in __gmap_zap()
  s390/gmap: don't unconditionally call pte_unmap_unlock() in
    __gmap_zap()
  s390/mm: validate VMA in PGSTE manipulation functions
  s390/mm: fix VMA and page table handling code in storage key handling
    functions
  s390/uv: fully validate the VMA before calling follow_page()
  s390/pci_mmio: fully validate the VMA before calling follow_pte()
  s390/mm: no need for pte_alloc_map_lock() if we know the pmd is
    present
  s390/mm: optimize set_guest_storage_key()
  s390/mm: optimize reset_guest_reference_bit()

 arch/s390/kernel/uv.c    |   2 +-
 arch/s390/mm/gmap.c      |  11 +++-
 arch/s390/mm/pgtable.c   | 109 +++++++++++++++++++++++++++------------
 arch/s390/pci/pci_mmio.c |   4 +-
 4 files changed, 89 insertions(+), 37 deletions(-)


base-commit: 7d2a07b769330c34b4deabeed939325c77a7ec2f
-- 
2.31.1


             reply	other threads:[~2021-09-09 16:24 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 16:22 David Hildenbrand [this message]
2021-09-09 16:22 ` [PATCH resend RFC 1/9] s390/gmap: validate VMA in __gmap_zap() David Hildenbrand
2021-09-14 16:53   ` Claudio Imbrenda
2021-09-09 16:22 ` [PATCH resend RFC 2/9] s390/gmap: don't unconditionally call pte_unmap_unlock() " David Hildenbrand
2021-09-14 16:52   ` Claudio Imbrenda
2021-09-09 16:22 ` [PATCH resend RFC 3/9] s390/mm: validate VMA in PGSTE manipulation functions David Hildenbrand
2021-09-14 16:54   ` Claudio Imbrenda
2021-09-09 16:22 ` [PATCH resend RFC 4/9] s390/mm: fix VMA and page table handling code in storage key handling functions David Hildenbrand
2021-09-27 16:37   ` Claudio Imbrenda
2021-09-09 16:22 ` [PATCH resend RFC 5/9] s390/uv: fully validate the VMA before calling follow_page() David Hildenbrand
2021-09-14 16:53   ` Claudio Imbrenda
2021-09-14 22:41   ` Liam Howlett
2021-09-09 16:22 ` [PATCH resend RFC 6/9] s390/pci_mmio: fully validate the VMA before calling follow_pte() David Hildenbrand
2021-09-14 16:54   ` Claudio Imbrenda
2021-09-14 22:41   ` Liam Howlett
2021-09-09 16:22 ` [PATCH resend RFC 7/9] s390/mm: no need for pte_alloc_map_lock() if we know the pmd is present David Hildenbrand
2021-09-14 16:54   ` Claudio Imbrenda
2021-09-14 17:23     ` David Hildenbrand
2021-09-09 16:22 ` [PATCH resend RFC 8/9] s390/mm: optimize set_guest_storage_key() David Hildenbrand
2021-09-27 17:01   ` Claudio Imbrenda
2021-09-09 16:22 ` [PATCH resend RFC 9/9] s390/mm: optimize reset_guest_reference_bit() David Hildenbrand
2021-09-27 17:02   ` Claudio Imbrenda
2021-09-14 16:50 ` [PATCH resend RFC 0/9] s390: fixes, cleanups and optimizations for page table walkers Claudio Imbrenda
2021-09-14 18:06   ` David Hildenbrand
2021-09-28 10:59 ` Heiko Carstens
2021-09-28 11:06   ` Christian Borntraeger
2021-09-28 14:38     ` Claudio Imbrenda
2021-09-28 16:03 ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210909162248.14969-1-david@redhat.com \
    --to=david@redhat.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=schnelle@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).