[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH v2] x86/p2m: tighten old-MFN check in p2m_add_page()
- To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 9 Feb 2023 16:32:42 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XQ+uHizeSoKLL3Pg9FTYVUHeQBMPxJ4WX+hi/cZJMcM=; b=iirNk3mT69twO5KdZXOBOmtPUiHCosjWxBvjvUGPKmui4TM38uy0n9mhyUuIcHyfMxwZ/GKU0KMIT3iHvuHyw1uevc+SNI8n4MwoScGvwcythapeyrbF7jF4O1EeRI6xeHuxCuLzTZpjgR0IgWZWBnvd7L3mE97PwqLTxXSWXcBwYh7nJdm9be74VFeaGqWs3Z9+4/jFv+Z133cBS2nbZ0skv5O8bknE/V293W5/hD0og+Qba6o/jqOKPlvdzoClbFxDOSx8fShHheGv7f6585Ua/9WVYL5piHQbnuwNDMwQgPP9DY6RBUVnkHtkgz0mINHipF/WVNlQ5LwTR/Ye2w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JAnyfNRi+ll36KzYeGyd6Dw++S0NlrJ9sMxHsWBpeFUYfkU9qFSXEa9a3M4NrVBCmK+vQJANqXyng/yfGi6gso7L3OwPiH2z1ilbYqYXLAR056xEVxg5qm4HOhtVYWWlkRKnebvMpiQ5cjA9lwFAOWdKjhN7x3TxvNRsLZCI6pZpmWHRw6kec+R97jC2soRVvcTWaLebgDntpvP27blC+TqGH4tjS8DEYULqGkDcUdhHmFRvVxPRscHilWYvMZDuwm6+XMQX+abR7Bd+ruSMluoEd6R9W9nDynU5FdtYHG999GajoZqp+LMaUq1y46NmI6A2DL0wJV8Ba3jFjiOODA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>
- Delivery-date: Thu, 09 Feb 2023 15:32:55 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Just ahead of the logic in question we've translated the subject MFN to
a valid original GFN, in order to then translate that GFN back to an
MFN. Restricting the call to p2m_remove_page() to the case where these
two MFNs match is too weak. Instead refuse the operation altogether when
there's a mismatch (which likely indicates a bug elsewhere in Xen), by
leveraging the checking in p2m_remove_entry() via passing in the
expected MFN.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
If we were certain that a mismatch indicates a bug elsewhere, we might
want to consider crashing the domain instead, to limit damage as well as
to make sure the issue is actually noticed.
---
v2: Drop the check rather than separating it out.
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -719,8 +719,7 @@ p2m_add_page(struct domain *d, gfn_t gfn
ASSERT(mfn_valid(omfn));
P2M_DEBUG("old gfn=%#lx -> mfn %#lx\n",
gfn_x(ogfn) , mfn_x(omfn));
- if ( mfn_eq(omfn, mfn_add(mfn, i)) &&
- (rc = p2m_remove_entry(p2m, ogfn, omfn, 0)) )
+ if ( (rc = p2m_remove_entry(p2m, ogfn, mfn_add(mfn, i), 0)) )
goto out;
}
}
|
