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

[Julien Grall <julien@xxxxxxx>]

Hi,

On 13/12/2022 23:05, Julien Grall wrote: > 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. 
I have looked at the series. It looks like there are only 16 patches 
left to be reviewed.
They are two years old but the code hasn't changed too much. So I will 
look at porting them over the next few days and hopefully I can respin 
the series before Christmas.
Cheers,
--
Julien Grall