linux-kernel - Re: [PATCH 2/5] KVM: x86/mmu: Fine-grained check of whether a invalid & RAM PFN is MMIO

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZjnyEQilJRK97HVB@yzhao56-desk.sh.intel.com>
Date: Tue, 7 May 2024 17:19:13 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>, "alex.williamson@...hat.com"
	<alex.williamson@...hat.com>, "jgg@...dia.com" <jgg@...dia.com>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"luto@...nel.org" <luto@...nel.org>, "peterz@...radead.org"
	<peterz@...radead.org>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"hpa@...or.com" <hpa@...or.com>, "corbet@....net" <corbet@....net>,
	"joro@...tes.org" <joro@...tes.org>, "will@...nel.org" <will@...nel.org>,
	"robin.murphy@....com" <robin.murphy@....com>, "baolu.lu@...ux.intel.com"
	<baolu.lu@...ux.intel.com>, "Liu, Yi L" <yi.l.liu@...el.com>
Subject: Re: [PATCH 2/5] KVM: x86/mmu: Fine-grained check of whether a
 invalid & RAM PFN is MMIO

On Tue, May 07, 2024 at 04:39:27PM +0800, Tian, Kevin wrote:
> > From: Zhao, Yan Y <yan.y.zhao@...el.com>
> > Sent: Tuesday, May 7, 2024 2:20 PM
> > @@ -101,9 +101,21 @@ static bool kvm_is_mmio_pfn(kvm_pfn_t pfn)
> >  			 */
> >  			(!pat_enabled() ||
> > pat_pfn_immune_to_uc_mtrr(pfn));
> > 
> > +	/*
> > +	 * If the PFN is invalid and not RAM in raw e820 table, keep treating it
> > +	 * as MMIO.
> > +	 *
> > +	 * If the PFN is invalid and is RAM in raw e820 table,
> > +	 * - if PAT is not enabled, always treat the PFN as MMIO to avoid
> > futher
> > +	 *   checking of MTRRs.
> > +	 * - if PAT is enabled, treat the PFN as MMIO if its PAT is UC/WC/UC-
> > in
> > +	 *   primary MMU.
> > +	 * to prevent guest cacheable access to MMIO PFNs.
> > +	 */
> >  	return !e820__mapped_raw_any(pfn_to_hpa(pfn),
> >  				     pfn_to_hpa(pfn + 1) - 1,
> > -				     E820_TYPE_RAM);
> > +				     E820_TYPE_RAM) ? true :
> > +				     (!pat_enabled() ||
> > pat_pfn_immune_to_uc_mtrr(pfn));
> 
> Is it for another theoretical problem in case the primary
> mmu uses a non-WB type on a invalid RAM-type pfn so
> you want to do additional scrutiny here?
Yes. Another untold reason is that patch 3 does not do CLFLUSH to this type of
memory since it's mapped as uncacheable in primary MMU. I feel that it's better
to ensure guest will not access it in cacheable memory type either.