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
| ||
|
Message-ID: <BYAPR21MB168853FD0676CCACF7C249B0D7A09@BYAPR21MB1688.namprd21.prod.outlook.com> Date: Thu, 16 Feb 2023 16:16:16 +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: Thursday, February 16, 2023 5:33 AM > > On Fri, Feb 10, 2023 at 11:47:27PM +0000, Sean Christopherson wrote: > > I agree with Boris' comment that a one-off "other encrypted range" is a hack, but > > that's just an API problem. The kernel already has hypervisor specific hooks (and > > for SEV-ES even), why not expand that? That way figuring out which devices are > > private is wholly contained in Hyper-V code, at least until there's a generic > > solution for enumerating private devices, though that seems unlikely to happen > > and will be a happy problem to solve if it does come about. > > I feel ya and this all makes sense and your proposals look clean enough > to me but we still need some way of determining whether this is a vTOM > on hyperv Historically, callbacks like Sean proposed default to NULL and do nothing unless they are explicitly set. The Hyper-V vTOM code would set the callback. Is that not sufficient? Or in the two places where the callback would be made, do you want to bracket with a test for being in a Hyper-V vTOM VM? If so, then we're back to needing something like CC_ATTR_PARAVISOR on which to gate the callbacks. Or do you mean something else entirely? Michael > because there's the next crapola with > > https://lore.kernel.org/all/20230209072220.6836-4-jgross@suse.com/ > > because apparently hyperv does PAT but disables MTRRs for such vTOM > SEV-SNP guests and ... madness. > > But that's not the only example - Xen has been doing this thing too. > > And Jürgen has been trying to address this in a clean way but it is > a pain. > > What I don't want to have is a gazillion ways to check what needs to > happen for which guest type. Because people who change the kernel to run > on baremetal, will break them. And I can't blame them. We try to support > all kinds of guests in the x86 code but this support should be plain and > simple. >
Powered by blists - more mailing lists