From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751155AbdFAMo6 (ORCPT ); Thu, 1 Jun 2017 08:44:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57410 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750952AbdFAMo4 (ORCPT ); Thu, 1 Jun 2017 08:44:56 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DEB3780C0E Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=david@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DEB3780C0E Subject: Re: [PATCH RFC 1/2] s390x: mm: allow mixed page table types (2k and 4k) To: Christian Borntraeger , kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Martin Schwidefsky , Heiko Carstens , Thomas Huth References: <20170529163202.13077-1-david@redhat.com> <20170529163202.13077-2-david@redhat.com> <2a3d5383-cab4-6882-4050-c69404bda347@de.ibm.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Thu, 1 Jun 2017 14:44:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <2a3d5383-cab4-6882-4050-c69404bda347@de.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 01 Jun 2017 12:44:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01.06.2017 13:39, Christian Borntraeger wrote: > On 05/29/2017 06:32 PM, David Hildenbrand wrote: > >> new = old = pgste_get_lock(ptep); >> pgste_val(new) &= ~(PGSTE_GR_BIT | PGSTE_GC_BIT | >> @@ -748,6 +764,11 @@ int reset_guest_reference_bit(struct mm_struct *mm, unsigned long addr) >> ptep = get_locked_pte(mm, addr, &ptl); >> if (unlikely(!ptep)) >> return -EFAULT; >> + if (!pgtable_has_pgste(mm, __pa(ptep))) { >> + pte_unmap_unlock(ptep, ptl); >> + WARN_ONCE(true, "Guest address on page table without pgste"); > > All these WARN_ONCE. Is there a way how a malicious user can trigger this or is this checked > everywhere and triggered would be indeed a bug? Very good question I added these for testing purposes, but leaving the WARN_ONCE here is wrong. The user can create memslots with "wrong" memory. Whenever such memory is linked into the gmap, we return -EFAULT. So we will only have page table with "pgstes" in our GMAP at any time. However, all these functions here go via memslots: test_and_clear_guest_dirty -> via memslot from memslot list set_guest_storage_key reset_guest_reference_bit get_guest_storage_key pgste_perform_essa set_pgste_bits get_pgste -> come via gfn_to_hva() -> gfn_to_memslot() -> search_memslots -> via memslot list And then use the calculated host address to just walk the ordinary process page tables (get_locked_pte) and not the pgste. So simply returning -EFAULT here is the right thing to, dropping the WARN_ONCE. Thanks! -- Thanks, David