Mailing List Archive

[PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted
In a AMD SEV-SNP VM using vTOM, devices in MMIO space may be provided by
the paravisor and need to be mapped as encrypted. Provide a function
for the hypervisor to specify the address range for such devices.
In __ioremap_caller(), map addresses in this range as encrypted.

Only a single range is supported. If multiple devices need to be
mapped encrypted, the paravisor must place them within the single
contiguous range.

Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
arch/x86/include/asm/io.h | 2 ++
arch/x86/mm/ioremap.c | 27 ++++++++++++++++++++++++++-
2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index e902564..72eb366 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -169,6 +169,8 @@ static inline unsigned int isa_virt_to_bus(volatile void *address)
}
#define isa_bus_to_virt phys_to_virt

+extern void ioremap_set_encrypted_range(resource_size_t addr, unsigned long size);
+
/*
* The default ioremap() behavior is non-cached; if you need something
* else, you probably want one of the following.
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 6453fba..8db5846 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -37,6 +37,10 @@ struct ioremap_desc {
unsigned int flags;
};

+/* Range of "other" addresses to treat as encrypted when remapping */
+resource_size_t other_encrypted_start;
+resource_size_t other_encrypted_end;
+
/*
* Fix up the linear direct mapping of the kernel to avoid cache attribute
* conflicts.
@@ -108,14 +112,35 @@ static unsigned int __ioremap_check_encrypted(struct resource *res)
}

/*
+ * Allow a hypervisor to specify an additional range of addresses to
+ * treat as encrypted when remapping.
+ */
+void ioremap_set_encrypted_range(resource_size_t addr, unsigned long size)
+{
+ other_encrypted_start = addr;
+ other_encrypted_end = addr + size - 1;
+}
+
+/*
* The EFI runtime services data area is not covered by walk_mem_res(), but must
- * be mapped encrypted when SEV is active.
+ * be mapped encrypted when SEV is active. Also check the hypervisor specified
+ * "other" address range to treat as encrypted.
*/
static void __ioremap_check_other(resource_size_t addr, struct ioremap_desc *desc)
{
if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
return;

+ /*
+ * Check for an address within the "other" encrypted address range. If such
+ * a range is set, it must include the entire space used by the device,
+ * so we don't need to deal with a partial fit.
+ */
+ if ((addr >= other_encrypted_start) && (addr <= other_encrypted_end)) {
+ desc->flags |= IORES_MAP_ENCRYPTED;
+ return;
+ }
+
if (!IS_ENABLED(CONFIG_EFI))
return;

--
1.8.3.1
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On Thu, Jan 12, 2023 at 01:42:25PM -0800, Michael Kelley wrote:
> In a AMD SEV-SNP VM using vTOM, devices in MMIO space may be provided by
> the paravisor and need to be mapped as encrypted. Provide a function
> for the hypervisor to specify the address range for such devices.
> In __ioremap_caller(), map addresses in this range as encrypted.
>
> Only a single range is supported. If multiple devices need to be
> mapped encrypted, the paravisor must place them within the single
> contiguous range.

This already is starting to sound insufficient and hacky. And it also makes
CC_ATTR_ACCESS_IOAPIC_ENCRYPTED insufficient either.

So, the situation we have is, we're a SEV-SNP VM using vTOM. Which means,
MSR_AMD64_SEV[3] = 1. Or SEV_FEATURES[1], alternatively - same thing.

That MSR cannot be intercepted by the HV and we use it extensively in Linux when
it runs as a SEV-* guest. And I had asked this before, during review, but why
aren't you checking this bit above when you wanna do vTOM-specific work?

Because then you can do that check and

1. map the IO-APIC encrypted
2. map MMIO space of devices from the driver encrypted too
3. ...

and so on.

And you won't need those other, not as nice things...

Hmmm.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Borislav Petkov <bp@alien8.de> Sent: Friday, January 20, 2023 12:15 PM
>
> On Thu, Jan 12, 2023 at 01:42:25PM -0800, Michael Kelley wrote:
> > In a AMD SEV-SNP VM using vTOM, devices in MMIO space may be provided by
> > the paravisor and need to be mapped as encrypted. Provide a function
> > for the hypervisor to specify the address range for such devices.
> > In __ioremap_caller(), map addresses in this range as encrypted.
> >
> > Only a single range is supported. If multiple devices need to be
> > mapped encrypted, the paravisor must place them within the single
> > contiguous range.
>
> This already is starting to sound insufficient and hacky. And it also makes
> CC_ATTR_ACCESS_IOAPIC_ENCRYPTED insufficient either.
>
> So, the situation we have is, we're a SEV-SNP VM using vTOM. Which means,
> MSR_AMD64_SEV[3] = 1. Or SEV_FEATURES[1], alternatively - same thing.
>
> That MSR cannot be intercepted by the HV and we use it extensively in Linux when
> it runs as a SEV-* guest. And I had asked this before, during review, but why
> aren't you checking this bit above when you wanna do vTOM-specific work?

Per the commit message for 009767dbf42a, it's not safe to read MSR_AMD64_SEV
on all implementations of AMD processors. CC_ATTR_ACCESS_IOAPIC_ENCRYPTED
is used in io_apic_set_fixmap(), which is called on all Intel/AMD systems without
any qualifications. Even if rdmsrl_safe() works at this point in boot, I'm a little
leery of reading a new MSR in a path that essentially every x86 bare-metal system
or VM takes during boot. Or am I being overly paranoid about old processor
models or hypervisor versions potentially doing something weird?

But in any case, the whole point of cc_platform_has() is to provide a level of
abstraction from the hardware registers, and it's fully safe to use on every x86
bare-metal system or VM. And while I don't anticipate it now, maybe there's
some future scheme where a paravisor-like entity could be used with Intel
TDX. It seems like using a cc_platform_has() abstraction is better than directly
accessing the MSR.

>
> Because then you can do that check and
>
> 1. map the IO-APIC encrypted
> 2. map MMIO space of devices from the driver encrypted too
> 3. ...

My resolution of the TPM driver issue is admittedly a work-around. I think
of it as temporary in anticipation of future implementations of PCIe TDISP
hardware, which allows PCI devices to DMA directly into guest encrypted
memory. TDISP also places the device's BAR values in an encrypted portion
of the GPA space. Assuming TDISP hardware comes along in the next couple
of years, Linux will need a robust way to deal with a mix of PCI devices
being in unencrypted and encrypted GPA space. I don't know how a
specific device will be mapped correctly, but I hope it can happen in the
generic PCI code, and not by modifying each device driver. It's probably
premature to build that robust mechanism now, but when it comes, my
work-around would be replaced.

With all that in mind, I don't want to modify the TPM driver to special-case
its MMIO space being encrypted. FWIW, the TPM driver today uses
devm_ioremap_resource() to do the mapping, which defaults to mapping
decrypted except for the exceptions implemented in __ioremap_caller().
There's no devm_* option for specifying encrypted. Handling decrypted
vs. encrypted in the driver would require extending the driver API to
provide an "encrypted" option, and that seems like going in the wrong
long-term direction.

Finally, I would have liked to handle the IO-APIC and the vTPM the same
way. But the IO-APIC doesn't use the normal ioremap_* functions because
it's done early in boot via the fixmap. I didn't see a reasonable way to
unify them.

Anyway, that's my thoughts. I'm certainly open if someone has a better
way to do it.

Michael

>
> and so on.
>
> And you won't need those other, not as nice things...
>
> Hmmm.
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On Sat, Jan 21, 2023 at 04:10:23AM +0000, Michael Kelley (LINUX) wrote:
> Per the commit message for 009767dbf42a, it's not safe to read MSR_AMD64_SEV
> on all implementations of AMD processors.

1. Why does that matter to you? This is Hygon.

2. The MSR access is behind CPUID check.

> CC_ATTR_ACCESS_IOAPIC_ENCRYPTED is used in io_apic_set_fixmap(), which is
> called on all Intel/AMD systems without any qualifications. Even if
> rdmsrl_safe() works at this point in boot, I'm a little leery of reading a new
> MSR in a path that essentially every x86 bare-metal system or VM takes during
> boot.

You read the MSR once and cache it. sme_enable() already does that. I don't see
what the problem is.

> Or am I being overly paranoid about old processor models or hypervisor
> versions potentially doing something weird?

Yes, you are. :)

If they're doing something weird which is out of spec, then we'll deal with them
later.

> But in any case, the whole point of cc_platform_has() is to provide a level of
> abstraction from the hardware registers, and it's fully safe to use on every x86
> bare-metal system or VM. And while I don't anticipate it now, maybe there's
> some future scheme where a paravisor-like entity could be used with Intel
> TDX. It seems like using a cc_platform_has() abstraction is better than directly
> accessing the MSR.

That's fine but we're talking about this particular implementation and that is
vTOM-like with the address space split. If TDX does address space split later,
we can accomodate it too. (Although I think they are not interested in this).

And if you really want to use cc_platform_has(), we could do

cc_platform_has(CC_ADDRESS_SPACE_SPLIT_ON_A_PARAVISOR)

or something with a better name.

The point is, you want to do things which are specific for this particular
implementation. If so, then check for it. Do not do hacky things which get the
work done for your case but can very easily be misused by others.

> My resolution of the TPM driver issue is admittedly a work-around. I think
> of it as temporary in anticipation of future implementations of PCIe TDISP
> hardware, which allows PCI devices to DMA directly into guest encrypted
> memory.

Yap, that sounds real nice.

> TDISP also places the device's BAR values in an encrypted portion
> of the GPA space. Assuming TDISP hardware comes along in the next couple
> of years, Linux will need a robust way to deal with a mix of PCI devices
> being in unencrypted and encrypted GPA space. I don't know how a
> specific device will be mapped correctly, but I hope it can happen in the
> generic PCI code, and not by modifying each device driver.

I guess those devices would advertize that capability somehow so that code can
query it and act accordingly.

> It's probably premature to build that robust mechanism now, but when it comes,
> my work-around would be replaced.

It would be replaced if it doesn't have any users. By the looks of it, it'll
soon grow others and then good luck removing it.

> With all that in mind, I don't want to modify the TPM driver to special-case
> its MMIO space being encrypted. FWIW, the TPM driver today uses
> devm_ioremap_resource() to do the mapping, which defaults to mapping
> decrypted except for the exceptions implemented in __ioremap_caller().
> There's no devm_* option for specifying encrypted.

You mean, it is hard to add a DEVM_IOREMAP_ENCRYPTED type which will have
__devm_ioremap() call ioremap_encrypted()?

Or define a IORESOURCE_ENCRYPTED and pass it through the ioresource flags?

Why is that TPM driver so precious that it can be touched and the arch code
would have to accept hacks?

> Handling decrypted vs. encrypted in the driver would require extending the
> driver API to provide an "encrypted" option, and that seems like going in the
> wrong long-term direction.

Sorry, I can't follow here.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Borislav Petkov <bp@alien8.de> Sent: Wednesday, January 25, 2023 6:56 AM
>
> On Sat, Jan 21, 2023 at 04:10:23AM +0000, Michael Kelley (LINUX) wrote:

[snip]

>
> > But in any case, the whole point of cc_platform_has() is to provide a level of
> > abstraction from the hardware registers, and it's fully safe to use on every x86
> > bare-metal system or VM. And while I don't anticipate it now, maybe there's
> > some future scheme where a paravisor-like entity could be used with Intel
> > TDX. It seems like using a cc_platform_has() abstraction is better than directly
> > accessing the MSR.
>
> That's fine but we're talking about this particular implementation and that is
> vTOM-like with the address space split. If TDX does address space split later,
> we can accomodate it too. (Although I think they are not interested in this).
>
> And if you really want to use cc_platform_has(), we could do
>
> cc_platform_has(CC_ADDRESS_SPACE_SPLIT_ON_A_PARAVISOR)
>
> or something with a better name.

I do think it makes sense to use the cc_platform_has() abstraction. It's
then a question of agreeing on how to name the attribute. We've
discussed various approaches in different versions of this patch series:

v1 & v2: CC_ATTR_HAS_PARAVISOR
v3: CC_ATTR_EMULATED_IOAPIC
v4 & v5: CC_ATTR_ACCESS_IOAPIC_ENCRYPTED

I could do:
1. CC_ATTR_PARAVISOR_SPLIT_ADDRESS_SPACE, which is similar to
what I had for v1 & v2. At the time, somebody commented that
this might be a bit too general.
2. Keep CC_ATTR_ACCESS_IOAPIC_ENCRYPTED and add
CC_ATTR_ACCESS_TPM_ENCRYPTED, which would decouple them
3. CC_ATTR_ACCESS_IOAPIC_AND_TPM_ENCRYPTED, which is very
narrow and specific.

I have weak preference for #1 above, but I could go with any of them.
What's your preference?

> > My resolution of the TPM driver issue is admittedly a work-around. I think
> > of it as temporary in anticipation of future implementations of PCIe TDISP
> > hardware, which allows PCI devices to DMA directly into guest encrypted
> > memory.
>
> Yap, that sounds real nice.
>
> > TDISP also places the device's BAR values in an encrypted portion
> > of the GPA space. Assuming TDISP hardware comes along in the next couple
> > of years, Linux will need a robust way to deal with a mix of PCI devices
> > being in unencrypted and encrypted GPA space. I don't know how a
> > specific device will be mapped correctly, but I hope it can happen in the
> > generic PCI code, and not by modifying each device driver.
>
> I guess those devices would advertize that capability somehow so that code can
> query it and act accordingly.
>
> > It's probably premature to build that robust mechanism now, but when it comes,
> > my work-around would be replaced.
>
> It would be replaced if it doesn't have any users. By the looks of it, it'll
> soon grow others and then good luck removing it.
>
> > With all that in mind, I don't want to modify the TPM driver to special-case
> > its MMIO space being encrypted. FWIW, the TPM driver today uses
> > devm_ioremap_resource() to do the mapping, which defaults to mapping
> > decrypted except for the exceptions implemented in __ioremap_caller().
> > There's no devm_* option for specifying encrypted.
>
> You mean, it is hard to add a DEVM_IOREMAP_ENCRYPTED type which will have
> __devm_ioremap() call ioremap_encrypted()?
>
> Or define a IORESOURCE_ENCRYPTED and pass it through the ioresource flags?
>
> Why is that TPM driver so precious that it can be touched and the arch code
> would have to accept hacks?
>
> > Handling decrypted vs. encrypted in the driver would require extending the
> > driver API to provide an "encrypted" option, and that seems like going in the
> > wrong long-term direction.
>
> Sorry, I can't follow here.
>

For v6 of the patch series, I've coded devm_ioremap_resource_enc() to call
__devm_ioremap(), which then calls ioremap_encrypted(). I've updated the
TPM driver to use cc_platform_has() with whatever attribute name we agree
on to decide between devm_ioremap_resource_enc() and
devm_ioremap_resource().

If this approach is OK with the TPM driver maintainers, I'm good with it.
More robust handling of a mix of encrypted and decrypted devices can get
sorted out later.

Michael
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On Thu, Feb 02, 2023 at 05:49:44AM +0000, Michael Kelley (LINUX) wrote:
> I could do:
> 1. CC_ATTR_PARAVISOR_SPLIT_ADDRESS_SPACE, which is similar to
> what I had for v1 & v2. At the time, somebody commented that
> this might be a bit too general.
> 2. Keep CC_ATTR_ACCESS_IOAPIC_ENCRYPTED and add
> CC_ATTR_ACCESS_TPM_ENCRYPTED, which would decouple them
> 3. CC_ATTR_ACCESS_IOAPIC_AND_TPM_ENCRYPTED, which is very
> narrow and specific.
>
> I have weak preference for #1 above, but I could go with any of them.
> What's your preference?

Either 1. but a shorter name or something which works with the TDX side
too.

Or are there no similar TDX solutions planned where the guest runs
unmodified and under a paravisor?

> For v6 of the patch series, I've coded devm_ioremap_resource_enc() to call
> __devm_ioremap(), which then calls ioremap_encrypted(). I've updated the
> TPM driver to use cc_platform_has() with whatever attribute name we agree
> on to decide between devm_ioremap_resource_enc() and
> devm_ioremap_resource().
>
> If this approach is OK with the TPM driver maintainers, I'm good with it.
> More robust handling of a mix of encrypted and decrypted devices can get
> sorted out later.

Makes sense to me...

Thx.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Borislav Petkov <bp@alien8.de> Sent: Tuesday, February 7, 2023 4:41 AM
>
> On Thu, Feb 02, 2023 at 05:49:44AM +0000, Michael Kelley (LINUX) wrote:
> > I could do:
> > 1. CC_ATTR_PARAVISOR_SPLIT_ADDRESS_SPACE, which is similar to
> > what I had for v1 & v2. At the time, somebody commented that
> > this might be a bit too general.
> > 2. Keep CC_ATTR_ACCESS_IOAPIC_ENCRYPTED and add
> > CC_ATTR_ACCESS_TPM_ENCRYPTED, which would decouple them
> > 3. CC_ATTR_ACCESS_IOAPIC_AND_TPM_ENCRYPTED, which is very
> > narrow and specific.
> >
> > I have weak preference for #1 above, but I could go with any of them.
> > What's your preference?
>
> Either 1. but a shorter name or something which works with the TDX side
> too.

Unless there are objections, I'll go with CC_ATTR_PARAVISOR_DEVICES,
which is shorter. The full details of the meaning will be in a comment
where this is defined with all the other CC_ATTR_* values.

>
> Or are there no similar TDX solutions planned where the guest runs
> unmodified and under a paravisor?

The TDX plans are still being sorted out. But if we end up with such
an approach, CC_ATTR_PARAVISOR_DEVICES will be correct for TDX
also.

Michael

>
> > For v6 of the patch series, I've coded devm_ioremap_resource_enc() to call
> > __devm_ioremap(), which then calls ioremap_encrypted(). I've updated the
> > TPM driver to use cc_platform_has() with whatever attribute name we agree
> > on to decide between devm_ioremap_resource_enc() and
> > devm_ioremap_resource().
> >
> > If this approach is OK with the TPM driver maintainers, I'm good with it.
> > More robust handling of a mix of encrypted and decrypted devices can get
> > sorted out later.
>
> Makes sense to me...
>
> Thx.
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On Tue, Feb 07, 2023 at 07:01:25PM +0000, Michael Kelley (LINUX) wrote:
> Unless there are objections, I'll go with CC_ATTR_PARAVISOR_DEVICES,

What does "DEVICES" mean in this context?

You need to think about !virt people too who are already confused by the
word "paravisor". :-)

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Borislav Petkov <bp@alien8.de> Sent: Tuesday, February 7, 2023 11:33 AM
>
> On Tue, Feb 07, 2023 at 07:01:25PM +0000, Michael Kelley (LINUX) wrote:
> > Unless there are objections, I'll go with CC_ATTR_PARAVISOR_DEVICES,
>
> What does "DEVICES" mean in this context?
>
> You need to think about !virt people too who are already confused by the
> word "paravisor". :-)
>

Maybe I misunderstood your previous comment about "Either 1". We can
avoid "PARAVISOR" entirely by going with two attributes:

CC_ATTR_ACCESS_IOAPIC_ENCRYPTED
CC_ATTR_ACCESS_TPM_ENCRYPTED

These are much more specific, and relatively short, and having two allows
decoupling the handling of the IO-APIC and TPM. Combining into the single

CC_ATTR_ACCESS_IOAPIC_AND_TPM_ENCRYPTED

also works but is longer.

Capturing the full meaning in the string names is probably impossible.
Referring to the comment for the definition will be required for a full
understanding.

Michael
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On Tue, Feb 07, 2023 at 07:48:06PM +0000, Michael Kelley (LINUX) wrote:
> From: Borislav Petkov <bp@alien8.de> Sent: Tuesday, February 7, 2023 11:33 AM
> >
> > On Tue, Feb 07, 2023 at 07:01:25PM +0000, Michael Kelley (LINUX) wrote:
> > > Unless there are objections, I'll go with CC_ATTR_PARAVISOR_DEVICES,
> >
> > What does "DEVICES" mean in this context?
> >
> > You need to think about !virt people too who are already confused by the
> > word "paravisor". :-)
> >
>
> Maybe I misunderstood your previous comment about "Either 1". We can
> avoid "PARAVISOR" entirely by going with two attributes:

No, I'm fine with CC_ATTR_PARAVISOR. Why would you have to have
CC_ATTR_PARAVISOR_DEVICES? I.e., the string "_DEVICES" appended after
"PARAVISOR". Isn't CC_ATTR_PARAVISOR enough?

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Borislav Petkov <bp@alien8.de> Sent: Tuesday, February 7, 2023 11:55 AM
>
> On Tue, Feb 07, 2023 at 07:48:06PM +0000, Michael Kelley (LINUX) wrote:
> > From: Borislav Petkov <bp@alien8.de> Sent: Tuesday, February 7, 2023 11:33 AM
> > >
> > > On Tue, Feb 07, 2023 at 07:01:25PM +0000, Michael Kelley (LINUX) wrote:
> > > > Unless there are objections, I'll go with CC_ATTR_PARAVISOR_DEVICES,
> > >
> > > What does "DEVICES" mean in this context?
> > >
> > > You need to think about !virt people too who are already confused by the
> > > word "paravisor". :-)
> > >
> >
> > Maybe I misunderstood your previous comment about "Either 1". We can
> > avoid "PARAVISOR" entirely by going with two attributes:
>
> No, I'm fine with CC_ATTR_PARAVISOR. Why would you have to have
> CC_ATTR_PARAVISOR_DEVICES? I.e., the string "_DEVICES" appended after
> "PARAVISOR". Isn't CC_ATTR_PARAVISOR enough?
>

Works for me. :-)

Michael
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Borislav Petkov <bp@alien8.de> Sent: Tuesday, February 7, 2023 11:55 AM
>
> On Tue, Feb 07, 2023 at 07:48:06PM +0000, Michael Kelley (LINUX) wrote:
> > From: Borislav Petkov <bp@alien8.de> Sent: Tuesday, February 7, 2023 11:33 AM
> > >
> > > On Tue, Feb 07, 2023 at 07:01:25PM +0000, Michael Kelley (LINUX) wrote:
> > > > Unless there are objections, I'll go with CC_ATTR_PARAVISOR_DEVICES,
> > >
> > > What does "DEVICES" mean in this context?
> > >
> > > You need to think about !virt people too who are already confused by the
> > > word "paravisor". :-)
> > >
> >
> > Maybe I misunderstood your previous comment about "Either 1". We can
> > avoid "PARAVISOR" entirely by going with two attributes:
>
> No, I'm fine with CC_ATTR_PARAVISOR. Why would you have to have
> CC_ATTR_PARAVISOR_DEVICES? I.e., the string "_DEVICES" appended after
> "PARAVISOR". Isn't CC_ATTR_PARAVISOR enough?
>

Dave --

In v2 of this patch series, you had concerns about CC_ATTR_PARAVISOR being too
generic. [1] After some back-and-forth discussion in this thread, Boris is back to
preferring it. Can you live with CC_ATTR_PARAVISOR? Just trying to reach
consensus ...

Michael

[1] https://lore.kernel.org/linux-hyperv/Y258BO8ohVtVZvSH@liuwe-devbox-debian-v2/T/#m593853d8094453ad3f1a5552dad995ccc6c019b2
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On 2/7/23 16:18, Michael Kelley (LINUX) wrote:
> In v2 of this patch series, you had concerns about CC_ATTR_PARAVISOR being too
> generic. [1] After some back-and-forth discussion in this thread, Boris is back to
> preferring it. Can you live with CC_ATTR_PARAVISOR? Just trying to reach
> consensus ...

I still think it's too generic. Even the comment was trying to be too
generic:

> + /**
> + * @CC_ATTR_HAS_PARAVISOR: Guest VM is running with a paravisor
> + *
> + * The platform/OS is running as a guest/virtual machine with
> + * a paravisor in VMPL0. Having a paravisor affects things
> + * like whether the I/O APIC is emulated and operates in the
> + * encrypted or decrypted portion of the guest physical address
> + * space.
> + *
> + * Examples include Hyper-V SEV-SNP guests using vTOM.
> + */
> + CC_ATTR_HAS_PARAVISOR,

This doesn't help me figure out when I should use CC_ATTR_HAS_PARAVISOR
really at all. It "operates in the encrypted or decrypted portion..."
Which one is it? Should I be adding or removing encryption on the
mappings for paravisors?

That's opposed to:

> + /**
> + * @CC_ATTR_ACCESS_IOAPIC_ENCRYPTED: Guest VM IO-APIC is encrypted
> + *
> + * The platform/OS is running as a guest/virtual machine with
> + * an IO-APIC that is emulated by a paravisor running in the
> + * guest VM context. As such, the IO-APIC is accessed in the
> + * encrypted portion of the guest physical address space.
> + *
> + * Examples include Hyper-V SEV-SNP guests using vTOM.
> + */
> + CC_ATTR_ACCESS_IOAPIC_ENCRYPTED,

Which makes this code almost stupidly obvious:

> - flags = pgprot_decrypted(flags);
> + if (!cc_platform_has(CC_ATTR_ACCESS_IOAPIC_ENCRYPTED))
> + flags = pgprot_decrypted(flags);

"Oh, if it's access is not encrypted, then get the decrypted version of
the flags."

Compare that to:

if (!cc_platform_has(CC_ATTR_PARAVISOR))
flags = pgprot_decrypted(flags);

Which is a big fat WTF. Because a paravisor "operates in the encrypted
or decrypted portion..." So is this if() condition correct or inverted?
It's utterly impossible to tell because of how generic the option is.

The only way to make sense of the generic thing is to do:

/* Paravisors have a decrypted IO-APIC mapping: */
if (!cc_platform_has(CC_ATTR_PARAVISOR))
flags = pgprot_decrypted(flags);

at every site to state the assumption and make the connection between
paravisors and the behavior. If you want to go do _that_, then fine by
me. But, at that point, the naming is pretty worthless because you
could also have said "goldfish" instead of "paravisor" and it makes an
equal amount of sense:

/* Goldfish have a decrypted IO-APIC mapping: */
if (!cc_platform_has(CC_ATTR_GOLDFISH))
flags = pgprot_decrypted(flags);

I get it, naming is hard.
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On 2/7/23 04:41, Borislav Petkov wrote:
> Or are there no similar TDX solutions planned where the guest runs
> unmodified and under a paravisor?

I actually don't think paravisors make *ANY* sense for Linux. If you
have to modify the guest, then just modify it to talk to the hypervisor
directly. This code is... modifying the guest. What does putting a
paravisor in the middle do for you?

It might help with binary drivers, but we don't do upstream kernel work
to make silly binary Linux drivers happy.

So, no, there's no similar TDX solutions planned, at least for Linux
guests. Unless I missed the memo. Kirill?
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Dave Hansen <dave.hansen@intel.com> Sent: Wednesday, February 8, 2023 7:10 AM
>
> On 2/7/23 16:18, Michael Kelley (LINUX) wrote:
> > In v2 of this patch series, you had concerns about CC_ATTR_PARAVISOR being too
> > generic. [1] After some back-and-forth discussion in this thread, Boris is back to
> > preferring it. Can you live with CC_ATTR_PARAVISOR? Just trying to reach
> > consensus ...
>
> I still think it's too generic. Even the comment was trying to be too
> generic:
>
> > + /**
> > + * @CC_ATTR_HAS_PARAVISOR: Guest VM is running with a paravisor
> > + *
> > + * The platform/OS is running as a guest/virtual machine with
> > + * a paravisor in VMPL0. Having a paravisor affects things
> > + * like whether the I/O APIC is emulated and operates in the
> > + * encrypted or decrypted portion of the guest physical address
> > + * space.
> > + *
> > + * Examples include Hyper-V SEV-SNP guests using vTOM.
> > + */
> > + CC_ATTR_HAS_PARAVISOR,
>
> This doesn't help me figure out when I should use CC_ATTR_HAS_PARAVISOR
> really at all. It "operates in the encrypted or decrypted portion..."
> Which one is it? Should I be adding or removing encryption on the
> mappings for paravisors?
>
> That's opposed to:
>
> > + /**
> > + * @CC_ATTR_ACCESS_IOAPIC_ENCRYPTED: Guest VM IO-APIC is encrypted
> > + *
> > + * The platform/OS is running as a guest/virtual machine with
> > + * an IO-APIC that is emulated by a paravisor running in the
> > + * guest VM context. As such, the IO-APIC is accessed in the
> > + * encrypted portion of the guest physical address space.
> > + *
> > + * Examples include Hyper-V SEV-SNP guests using vTOM.
> > + */
> > + CC_ATTR_ACCESS_IOAPIC_ENCRYPTED,
>
> Which makes this code almost stupidly obvious:
>
> > - flags = pgprot_decrypted(flags);
> > + if (!cc_platform_has(CC_ATTR_ACCESS_IOAPIC_ENCRYPTED))
> > + flags = pgprot_decrypted(flags);
>
> "Oh, if it's access is not encrypted, then get the decrypted version of
> the flags."
>
> Compare that to:
>
> if (!cc_platform_has(CC_ATTR_PARAVISOR))
> flags = pgprot_decrypted(flags);
>
> Which is a big fat WTF. Because a paravisor "operates in the encrypted
> or decrypted portion..." So is this if() condition correct or inverted?
> It's utterly impossible to tell because of how generic the option is.
>
> The only way to make sense of the generic thing is to do:
>
> /* Paravisors have a decrypted IO-APIC mapping: */
> if (!cc_platform_has(CC_ATTR_PARAVISOR))
> flags = pgprot_decrypted(flags);
>
> at every site to state the assumption and make the connection between
> paravisors and the behavior. If you want to go do _that_, then fine by
> me. But, at that point, the naming is pretty worthless because you
> could also have said "goldfish" instead of "paravisor" and it makes an
> equal amount of sense:
>
> /* Goldfish have a decrypted IO-APIC mapping: */
> if (!cc_platform_has(CC_ATTR_GOLDFISH))
> flags = pgprot_decrypted(flags);
>
> I get it, naming is hard.

Boris --

Any further comments? Trying to reach consensus. A
solution aligned with Dave's arguments would keep the current
CC_ATTR_ACCESS_IOAPIC_ENCRYPTED, and add
CC_ATTR_ACCESS_TPM_ENCRYPTED to cover the TPM case,
which decouples the two.

Yes, naming is hard. Reaching consensus on naming is even
harder. :-)

Michael
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Dave Hansen <dave.hansen@intel.com> Sent: Wednesday, February 8, 2023 9:24 AM
>
> On 2/7/23 04:41, Borislav Petkov wrote:
> > Or are there no similar TDX solutions planned where the guest runs
> > unmodified and under a paravisor?
>
> I actually don't think paravisors make *ANY* sense for Linux. If you
> have to modify the guest, then just modify it to talk to the hypervisor
> directly. This code is... modifying the guest. What does putting a
> paravisor in the middle do for you?

One of the original goals of the paravisor was to make fewer
modifications to the guest, especially in areas that aren't directly related
to the hypervisor. It's arguable as to whether that goal played out in
reality.

But another significant goal is to be able to move some device emulation
from the hypervisor/VMM to the guest context. In a CoCo VM, this move
is from outside the TCB to inside the TCB. A great example is a virtual
TPM. Per the CoCo VM threat model, a guest can't rely on a vTPM
provided by the host. But a guest *can* rely on a vTPM implemented in
a more privileged layer of the guest context. With CoCo VMs in the
Azure public cloud, the paravisor also provides other device emulation, like
the IO-APIC to solve some of the ugly interrupt delivery issues. In a
complete solution, it should be possible for a customer to provide his
own paravisor, or at least to inspect/audit the vendor-provided paravisor
code so that it can be certified against whatever security standards the
customer requires. For Azure CoCo VMs, this part is a work-in-progress.

This could turn into an extended discussion, and I've given only a
fairly high-level answer. There are architects at Microsoft who could
probably give a better rendition of why we've pursued the paravisor
approach with SEV-SNP guests.

Michael

>
> It might help with binary drivers, but we don't do upstream kernel work
> to make silly binary Linux drivers happy.
>
> So, no, there's no similar TDX solutions planned, at least for Linux
> guests. Unless I missed the memo. Kirill?
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
Wearing my KVM hat and not my Google hat...

On Thu, Feb 09, 2023, Michael Kelley (LINUX) wrote:
> From: Dave Hansen <dave.hansen@intel.com> Sent: Wednesday, February 8, 2023 9:24 AM
> >
> > On 2/7/23 04:41, Borislav Petkov wrote:
> > > Or are there no similar TDX solutions planned where the guest runs
> > > unmodified and under a paravisor?
> >
> > I actually don't think paravisors make *ANY* sense for Linux.

I 100% agree, but Intel made what I think almost entirely irrelevant by refusing
to allow third party code to run in SEAM.

> > If you have to modify the guest, then just modify it to talk to the
> > hypervisor directly. This code is... modifying the guest. What does
> > putting a paravisor in the middle do for you?
>
> One of the original goals of the paravisor was to make fewer
> modifications to the guest, especially in areas that aren't directly related
> to the hypervisor. It's arguable as to whether that goal played out in
> reality.
>
> But another significant goal is to be able to move some device emulation
> from the hypervisor/VMM to the guest context. In a CoCo VM, this move
> is from outside the TCB to inside the TCB. A great example is a virtual
> TPM. Per the CoCo VM threat model, a guest can't rely on a vTPM
> provided by the host.

I vehemently disagree with this assertion. It's kinda sorta true, but only
because Intel and AMD have gone down the road of not providing the mechanisms and
ability for the hypervisor to run and attest to the integrity, functionality, etc.
of (a subset of) the hypervisor's own code.

Taking SEAM/TDX as an example, if the code running in SEAM were an extension of
KVM instead of a hypervisor-agnostic nanny, then there would be no need for a
"paravisor" to provide a vTPM. It would be very feasible to teach the SEAM-protected
bits of KVM to forward vTPM accesses to a host-provided, signed, attested, and open
source software running in a helper TD.

I fully realize you meant "untrusted host", but statements like "the host can't
be trusted" subconciously reinforce the, IMO, flawed model of hardware vendors
and _only_ hardware vendors providing the trusted bits.

The idea that firmware/software written by hardware vendors is somehow more
trustworthy than fully open source software is simultaneously laughable and
infuriating.

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.
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On 2/10/23 10:41, 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.

Did you like the more wordy per-device flags better? Or did you have
something else in mind entirely?
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
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.

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.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Borislav Petkov <bp@alien8.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.
>
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On Fri, Feb 10, 2023 at 07:15:41PM +0000, Michael Kelley (LINUX) wrote:
> 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.

What happens if the next silly HV guest scheme comes along and they do
need more and different ones?

Do I say, but but, Michael said that he doubted at the time that that
list would grow... ;-\

And then all our paths are sprinkled with

if (cc_platform_has())

and we can't change sh*t anymore out of fear that some weird guest type
will break.

> 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.

There's a reason the word "platform" is in cc_platform_has(). Initially
we wanted to distinguish attributes of the different platforms. So even
if y'all don't like CC_ATTR_PARAVISOR, that is what distinguishes this
platform and it *is* one platform.

So call it CC_ATTR_SEV_VTOM as it uses that technology or whatever. But
call it like the platform, not to mean "I need this functionality".

And yes, we could do the regroupings later because, yeah, those things
are not exposed to userspace so it's not like they're cast in stone but
I fear that we will do regroupings and we will break guests.

Now if you had CC_ATTR_<PLATFORM_TYPE> then you break (or not) only that
platform.

Oh, and then there's the thing that this is kernel proper - that code
still runs on real hardware, for now, and is not only guests. And not
everything is a damn cloud.

So I don't want a zoo here and we'd have to agree to distinguish by
platform and not by different functionality required.

Thx.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On 2/10/23 11:36, Borislav Petkov wrote:
>> 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.
> There's a reason the word "platform" is in cc_platform_has(). Initially
> we wanted to distinguish attributes of the different platforms. So even
> if y'all don't like CC_ATTR_PARAVISOR, that is what distinguishes this
> platform and it *is* one platform.
>
> So call it CC_ATTR_SEV_VTOM as it uses that technology or whatever. But
> call it like the platform, not to mean "I need this functionality".

I can live with that. There's already a CC_ATTR_GUEST_SEV_SNP, so it
would at least not be too much of a break from what we already have.
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On Fri, Feb 10, 2023, Dave Hansen wrote:
> On 2/10/23 11:36, Borislav Petkov wrote:
> >> 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.
> > There's a reason the word "platform" is in cc_platform_has(). Initially
> > we wanted to distinguish attributes of the different platforms. So even
> > if y'all don't like CC_ATTR_PARAVISOR, that is what distinguishes this
> > platform and it *is* one platform.
> >
> > So call it CC_ATTR_SEV_VTOM as it uses that technology or whatever. But
> > call it like the platform, not to mean "I need this functionality".
>
> I can live with that. There's already a CC_ATTR_GUEST_SEV_SNP, so it
> would at least not be too much of a break from what we already have.

I'm fine with CC_ATTR_SEV_VTOM, assuming the proposal is to have something like:

static inline bool is_address_range_private(resource_size_t addr)
{
if (cc_platform_has(CC_ATTR_SEV_VTOM))
return is_address_below_vtom(addr);

return false;
}

i.e. not have SEV_VTOM mean "I/O APIC and vTPM are private". Though I don't see
the point in making it SEV vTOM specific or using a flag. Despite what any of us
think about TDX paravisors, it's completely doable within the confines of TDX to
have an emulated device reside in the private address space. E.g. why not
something like this?

static inline bool is_address_range_private(resource_size_t addr)
{
return addr < cc_platform_private_end;
}

where SEV fills in "cc_platform_private_end" when vTOM is enabled, and TDX does
the same. Or wrap cc_platform_private_end in a helper, etc.
Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
On Fri, Feb 10, 2023, Sean Christopherson wrote:
> On Fri, Feb 10, 2023, Dave Hansen wrote:
> > On 2/10/23 11:36, Borislav Petkov wrote:
> > >> 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.
> > > There's a reason the word "platform" is in cc_platform_has(). Initially
> > > we wanted to distinguish attributes of the different platforms. So even
> > > if y'all don't like CC_ATTR_PARAVISOR, that is what distinguishes this
> > > platform and it *is* one platform.
> > >
> > > So call it CC_ATTR_SEV_VTOM as it uses that technology or whatever. But
> > > call it like the platform, not to mean "I need this functionality".
> >
> > I can live with that. There's already a CC_ATTR_GUEST_SEV_SNP, so it
> > would at least not be too much of a break from what we already have.
>
> I'm fine with CC_ATTR_SEV_VTOM, assuming the proposal is to have something like:
>
> static inline bool is_address_range_private(resource_size_t addr)
> {
> if (cc_platform_has(CC_ATTR_SEV_VTOM))
> return is_address_below_vtom(addr);
>
> return false;
> }
>
> i.e. not have SEV_VTOM mean "I/O APIC and vTPM are private". Though I don't see
> the point in making it SEV vTOM specific or using a flag. Despite what any of us
> think about TDX paravisors, it's completely doable within the confines of TDX to
> have an emulated device reside in the private address space. E.g. why not
> something like this?
>
> static inline bool is_address_range_private(resource_size_t addr)
> {
> return addr < cc_platform_private_end;
> }
>
> where SEV fills in "cc_platform_private_end" when vTOM is enabled, and TDX does
> the same. Or wrap cc_platform_private_end in a helper, etc.

Gah, forgot that the intent with TDX is to enumerate devices in their legacy
address spaces. So a TDX guest couldn't do this by default, but if/when Hyper-V
or some other hypervisor moves I/O APIC, vTPM, etc... into the TCB, the common
code would just work and only the hypervisor-specific paravirt code would need
to change.

Probably need a more specific name than is_address_range_private() though, e.g.
is_mmio_address_range_private()?
RE: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted [ In reply to ]
From: Sean Christopherson <seanjc@google.com> Sent: Friday, February 10, 2023 12:58 PM
>
> On Fri, Feb 10, 2023, Sean Christopherson wrote:
> > On Fri, Feb 10, 2023, Dave Hansen wrote:
> > > On 2/10/23 11:36, Borislav Petkov wrote:
> > > >> 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.
> > > > There's a reason the word "platform" is in cc_platform_has(). Initially
> > > > we wanted to distinguish attributes of the different platforms. So even
> > > > if y'all don't like CC_ATTR_PARAVISOR, that is what distinguishes this
> > > > platform and it *is* one platform.
> > > >
> > > > So call it CC_ATTR_SEV_VTOM as it uses that technology or whatever. But
> > > > call it like the platform, not to mean "I need this functionality".
> > >
> > > I can live with that. There's already a CC_ATTR_GUEST_SEV_SNP, so it
> > > would at least not be too much of a break from what we already have.
> >
> > I'm fine with CC_ATTR_SEV_VTOM, assuming the proposal is to have something like:
> >
> > static inline bool is_address_range_private(resource_size_t addr)
> > {
> > if (cc_platform_has(CC_ATTR_SEV_VTOM))
> > return is_address_below_vtom(addr);
> >
> > return false;
> > }
> >
> > i.e. not have SEV_VTOM mean "I/O APIC and vTPM are private". Though I don't see
> > the point in making it SEV vTOM specific or using a flag. Despite what any of us
> > think about TDX paravisors, it's completely doable within the confines of TDX to
> > have an emulated device reside in the private address space. E.g. why not
> > something like this?
> >
> > static inline bool is_address_range_private(resource_size_t addr)
> > {
> > return addr < cc_platform_private_end;
> > }
> >
> > where SEV fills in "cc_platform_private_end" when vTOM is enabled, and TDX does
> > the same. Or wrap cc_platform_private_end in a helper, etc.
>
> Gah, forgot that the intent with TDX is to enumerate devices in their legacy
> address spaces. So a TDX guest couldn't do this by default, but if/when Hyper-V
> or some other hypervisor moves I/O APIC, vTPM, etc... into the TCB, the common
> code would just work and only the hypervisor-specific paravirt code would need
> to change.
>
> Probably need a more specific name than is_address_range_private() though, e.g.
> is_mmio_address_range_private()?

Maybe I'm not understanding what you are proposing, but in an SEV-SNP
VM using vTOM, devices like the IO-APIC and TPM live at their usual guest
physical addresses. The question is whether the kernel virtual mapping
should be set up with encryption enabled or disabled. That question can't
be answered by looking at the device's address. Whether to map a particular
device with encryption enabled really is a property of the "platform" because
it depends on whether the paravisor is emulating the device. Having the
paravisor emulate the device does not change its guest physical address.

While there's a duality, it's better to think of the vTOM bit as the
"encryption" flag in the PTE rather than part of the guest physical address.
A key part of this patch series is about making that shift in how the vTOM
bit is treated. With the change, the vTOM bit is treated pretty much the
same as the TDX SHARED flag.

Michael

1 2 3  View All