Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp630546imj; Thu, 7 Feb 2019 09:24:35 -0800 (PST) X-Google-Smtp-Source: AHgI3IZh/t5cufF2BdcwqHg7KsRiGogfMTfbkcH0qJjHw34Ts3qlypojWhqW0KRmQAyjWezYURZZ X-Received: by 2002:a62:6503:: with SMTP id z3mr16826595pfb.169.1549560275172; Thu, 07 Feb 2019 09:24:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549560275; cv=none; d=google.com; s=arc-20160816; b=wud5SEhzGkM1XHHWyp5Fk/1R2Z3yR/lGDafMBeWoMylQpip/tm24mFImFSP5v428rl biXouYfnlrGF2rN+4Cnu/CcZDJCXY1fWqPFP98N4Ko7+9TAzC/OitrVdYrfPSW8t0gYu 0SUMrpIcqI5kVvpgskeAp7IRTZzMhHgpP7H2PXULkC0RZwvR3ayRx4PCGAspFbg3tb9U PSyx2L1xd25c5yhW6zzD+8jikM2sZWO3yiGrFZRq5tRZzkw6w7PZCFxKlfg6N+ZsE7SK ehPTHJVKZjivgbvoL4A/ElBitNj1R+4z9KdkjaGyjrNha+58nSOguaHX8NQkUr4BuaDd fuHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=clhLtWnBcok1FmHpjAAYMn6otLqYg8XV8C+zAhPQ1Tw=; b=ktF1t++///C/vYIslMnCqp7lFbLsHo6cZoQQzc8GuDI9NAcCIiZVqPLajLI/gfA/6/ X5Ce3/NUURBframXGuGMPgHwkKAzzXKHwYxD/5uggzNfk0DCsCvsRDgBN1AO0TGw3whj nlzc+4u07DnbpWoNm79DzwkiZ3jgCkOVa7MMkfe9HZMoNOKTPXtKnm1DfUby3P1edcn1 0lwwcu5xATmINeMIVEuG9To87cD+zypJpM/2KvsuGPAX9CE8hS/OZ8i0HbkG06n6dbVb OTBJbzkOst94uVkQ2dtw5f1/PNLsBGIcbHQpIR8ZDPIpk2Pj9w7pFjhZiQwH7B5RWKvJ m4oQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fdo6Zk9g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5si8820225pgw.377.2019.02.07.09.24.17; Thu, 07 Feb 2019 09:24:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fdo6Zk9g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726858AbfBGRXs (ORCPT + 99 others); Thu, 7 Feb 2019 12:23:48 -0500 Received: from mail-it1-f194.google.com ([209.85.166.194]:35483 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726270AbfBGRXs (ORCPT ); Thu, 7 Feb 2019 12:23:48 -0500 Received: by mail-it1-f194.google.com with SMTP id r6so1699052itk.0; Thu, 07 Feb 2019 09:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=clhLtWnBcok1FmHpjAAYMn6otLqYg8XV8C+zAhPQ1Tw=; b=fdo6Zk9g7g7EfVEf/3RIGE04zgWulg0MOtZGm7Nzchn+oHHQyj4gYG05+jEQNaXCrK GG51Pdtkqd8UF/PTX+7HJrDOjtbHsOlTivVoW6SaxobTcoQ86VX2WKFSr/Sghr8w80Cq +/V6Cs1DHTdqkIMI62WO4wKuKVzMrYfz2YoHsQnDHl49Hl7icLz9Rs4iwOx7gdKQaH2l BgVpTYYyC2gcy8gnguDGg9Z1JMYbJFH9V9B/8jVJmXD9D3UbPeWQt320iFA8W1xfGWUm tgas69UnvDXQeoqKucZXywn1PYXJf3aVcVNU7085K8n3bDrXjiAaUGfJTKI9zBfgbU2m JCwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=clhLtWnBcok1FmHpjAAYMn6otLqYg8XV8C+zAhPQ1Tw=; b=AJ+WdR8RNjEEW6bBQIEBW/wjlK2tMlKz6P/ewxhUVqpiNfVEm/Dhe2PiPI7TyLFdKx 7oz+Dif6d2eVTlfH2MJRqKojlcHcwYAxbw1MIhJYzlHP6Sh0FIIRuLwTlPDs62Z/9+MZ ej8P0iNV3rbACemajxQlzWO6TbSQ3xJ0zTefq1Qg0HGaq0bBbw6gHXDylRXBOD7D0zkR 6OPZL5+5Mx6QTYbT9ZKy3cZLs65vsOLtpWLKopHro0BgZATPU6sQYJFq41Hi2TxkkBTQ JlHJNaOfadNPEGK77HhQ3QH60MlLkpVRaAgP09Xpk70dnTBf+iLTmm0nfFLkA1zLVoaa GdiQ== X-Gm-Message-State: AHQUAuaRBz9eyT0vd+ErSAdu4LpLcrRYEoRNzO+cG3qlInkQSX3iSJvY 28nGEiWnsUDFa40C4dd/JPkb0WmfQUuEikQ43/g= X-Received: by 2002:a5e:8c14:: with SMTP id n20mr359163ioj.200.1549560226974; Thu, 07 Feb 2019 09:23:46 -0800 (PST) MIME-Version: 1.0 References: <20190204201854.2328-1-nitesh@redhat.com> <20190204201854.2328-5-nitesh@redhat.com> In-Reply-To: <20190204201854.2328-5-nitesh@redhat.com> From: Alexander Duyck Date: Thu, 7 Feb 2019 09:23:35 -0800 Message-ID: Subject: Re: [RFC][Patch v8 4/7] KVM: Disabling page poisoning to prevent corruption To: Nitesh Narayan Lal Cc: kvm list , LKML , Paolo Bonzini , lcapitulino@redhat.com, pagupta@redhat.com, wei.w.wang@intel.com, Yang Zhang , riel@surriel.com, david@redhat.com, "Michael S. Tsirkin" , dodgen@google.com, Konrad Rzeszutek Wilk , dhildenb@redhat.com, Andrea Arcangeli Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 4, 2019 at 2:11 PM Nitesh Narayan Lal wrote: > > This patch disables page poisoning if guest page hinting is enabled. > It is required to avoid possible guest memory corruption errors. > Page Poisoning is a feature in which the page is filled with a specific > pattern of (0x00 or 0xaa) after arch_free_page and the same is verified > before arch_alloc_page to prevent following issues: > *information leak from the freed data > *use after free bugs > *memory corruption > Selection of the pattern depends on the CONFIG_PAGE_POISONING_ZERO > Once the guest pages which are supposed to be freed are sent to the > hypervisor it frees them. After freeing the pages in the global list > following things may happen: > *Hypervisor reallocates the freed memory back to the guest > *Hypervisor frees the memory and maps a different physical memory > In order to prevent any information leak hypervisor before allocating > memory to the guest fills it with zeroes. > The issue arises when the pattern used for Page Poisoning is 0xaa while > the newly allocated page received from the hypervisor by the guest is > filled with the pattern 0x00. This will result in memory corruption errors. > > Signed-off-by: Nitesh Narayan Lal This seems kind of backwards to me. Why disable page poisoning instead of just not hinting about the free pages? There shouldn't be that many instances when page poisoning is enabled, and when it is it would make more sense to leave it enabled rather than silently disable it. > --- > include/linux/page_hinting.h | 8 ++++++++ > mm/page_poison.c | 2 +- > virt/kvm/page_hinting.c | 1 + > 3 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h > index 2d7ff59f3f6a..e800c6b07561 100644 > --- a/include/linux/page_hinting.h > +++ b/include/linux/page_hinting.h > @@ -19,7 +19,15 @@ struct hypervisor_pages { > extern int guest_page_hinting_flag; > extern struct static_key_false guest_page_hinting_key; > extern struct smp_hotplug_thread hinting_threads; > +extern bool want_page_poisoning; > > int guest_page_hinting_sysctl(struct ctl_table *table, int write, > void __user *buffer, size_t *lenp, loff_t *ppos); > void guest_free_page(struct page *page, int order); > + > +static inline void disable_page_poisoning(void) > +{ > +#ifdef CONFIG_PAGE_POISONING > + want_page_poisoning = 0; > +#endif > +} > diff --git a/mm/page_poison.c b/mm/page_poison.c > index f0c15e9017c0..9af96021133b 100644 > --- a/mm/page_poison.c > +++ b/mm/page_poison.c > @@ -7,7 +7,7 @@ > #include > #include > > -static bool want_page_poisoning __read_mostly; > +bool want_page_poisoning __read_mostly; > > static int __init early_page_poison_param(char *buf) > { > diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c > index 636990e7fbb3..be529f6f2bc0 100644 > --- a/virt/kvm/page_hinting.c > +++ b/virt/kvm/page_hinting.c > @@ -103,6 +103,7 @@ void guest_free_page(struct page *page, int order) > > local_irq_save(flags); > if (page_hinting_obj->kvm_pt_idx != MAX_FGPT_ENTRIES) { > + disable_page_poisoning(); > page_hinting_obj->kvm_pt[page_hinting_obj->kvm_pt_idx].pfn = > page_to_pfn(page); > page_hinting_obj->kvm_pt[page_hinting_obj->kvm_pt_idx].zonenum = At a minimum it seems like you should have some sort of warning message that you are disabling page poisoning rather than just silently turning it off.