[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR21MB16882083E84F20B906E2C847D7DE9@BYAPR21MB1688.namprd21.prod.outlook.com>
Date: Fri, 10 Feb 2023 19:15:41 +0000
From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To: Borislav Petkov <bp@...en8.de>,
Sean Christopherson <seanjc@...gle.com>
CC: Dave Hansen <dave.hansen@...el.com>,
"hpa@...or.com" <hpa@...or.com>, KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
Dexuan Cui <decui@...rosoft.com>,
"luto@...nel.org" <luto@...nel.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"lpieralisi@...nel.org" <lpieralisi@...nel.org>,
"robh@...nel.org" <robh@...nel.org>, "kw@...ux.com" <kw@...ux.com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"arnd@...db.de" <arnd@...db.de>, "hch@....de" <hch@....de>,
"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
"robin.murphy@....com" <robin.murphy@....com>,
"thomas.lendacky@....com" <thomas.lendacky@....com>,
"brijesh.singh@....com" <brijesh.singh@....com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
Tianyu Lan <Tianyu.Lan@...rosoft.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"isaku.yamahata@...el.com" <isaku.yamahata@...el.com>,
"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
"jane.chu@...cle.com" <jane.chu@...cle.com>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
Subject: RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range
to map as encrypted
From: Borislav Petkov <bp@...en8.de> Sent: Friday, February 10, 2023 11:04 AM
>
> On Fri, Feb 10, 2023 at 06:41:54PM +0000, Sean Christopherson wrote:
> > Anyways, tying things back to the actual code being discussed, I vote against
> > CC_ATTR_PARAVISOR. Being able to trust device emulation is not unique to a
> > paravisor. A single flag also makes too many assumptions about what is trusted
> > and thus should be accessed encrypted.
>
> I'm not crazy about the alternative either: one flag per access type:
> IO APIC, vTPM, and soon.
>
FWIW, I don't think the list of devices to be accessed encrypted is likely
to grow significantly. Is one or two more possible? Perhaps. Does it
become a list of ten? I doubt it.
One approach is to go with the individual device attributes for now.
If the list does grow significantly, there will probably be patterns
or groupings that we can't discern now. We could restructure into
larger buckets at that point based on those patterns/groupings.
Michael
>
> Soon this will become an unmaintainable zoo of different guest types
> people want the kernel to support. I don't think I want that madness in
> kernel proper.
>
Powered by blists - more mailing lists