Re: [RFC 0/4] Adding Virtual Memory Fuses to Xen

[Julien Grall <julien@xxxxxxx>]

Hi Demi,

On 13/12/2022 22:22, Demi Marie Obenour wrote:
> On Tue, Dec 13, 2022 at 08:55:28PM +0000, Julien Grall wrote:
> > On 13/12/2022 19:48, Smith, Jackson wrote:
> > > Hi Xen Developers,
> > Hi Jackson,
> >
> > Thanks for sharing the prototype with the community. Some questions/remarks
> > below.
> [snip]
>
> > > With this technique, we protect the integrity and confidentiality of
> > > guest memory. However, a compromised hypervisor can still read/write
> > > register state during traps, or refuse to schedule a guest, denying
> > > service. We also recognize that because this technique precludes
> > > modifying Xen's page tables after startup, it may not be compatible
> > > with all of Xen's potential use cases. On the other hand, there are
> > > some uses cases (in particular statically defined embedded systems)
> > > where our technique could be adopted with minimal friction.
> >  From what you wrote, this sounds very much like the project Citrix and
> > Amazon worked on called "Secret-free hypervisor" with a twist. In your case,
> > you want to prevent the hypervisor to map/unmap the guest memory.
> >
> > You can find some details in [1]. The code is x86 only, but I don't see any
> > major blocker to port it on arm64.
> Is there any way the secret-free hypervisor code could be upstreamed?
This has been in my todo list for more than year but didn't yet find 
anyone to finish the work.
I need to have a look how much left the original work it is left to do. 
Would you be interested to contribute?
> My understanding is that it would enable guests to use SMT without
> risking the host, which would be amazing.
>
> > >         Virtualized MMIO on arm needs to decode certain load/store
> > >         instructions
> > On Arm, this can be avoided of the guest OS is not using such instruction.
> > In fact they were only added to cater "broken" guest OS.
> >
> > Also, this will probably be a lot more difficult on x86 as, AFAIK, there is
> > no instruction syndrome. So you will need to decode the instruction in order
> > to emulate the access.
> Is requiring the guest to emulate such instructions itself an option?
> μXen, SEV-SNP, and TDX all do this.

I am not very familiar with this. So a few questions:
 * Does this mean the OS needs to be modified?
 * What happen for emulated device?

Cheers,

--
Julien Grall