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

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 16/12/2022 01:46, Stefano Stabellini wrote:
> On Thu, 15 Dec 2022, Julien Grall wrote:
> > > > On 13/12/2022 19:48, Smith, Jackson wrote:
> > > Yes, we are familiar with the "secret-free hypervisor" work. As you
> > > point out, both our work and the secret-free hypervisor remove the
> > > directmap region to mitigate the risk of leaking sensitive guest
> > > secrets. However, our work is slightly different because it additionally
> > > prevents attackers from tricking Xen into remapping a guest.
> > I understand your goal, but I don't think this is achieved (see above). You
> > would need an entity to prevent write to TTBR0_EL2 in order to fully protect
> > it.
> Without a way to stop Xen from reading/writing TTBR0_EL2, we cannot
> claim that the guest's secrets are 100% safe.
>
> But the attacker would have to follow the sequence you outlines above to
> change Xen's pagetables and remap guest memory before accessing it. It
> is an additional obstacle for attackers that want to steal other guests'
> secrets. The size of the code that the attacker would need to inject in
> Xen would need to be bigger and more complex.
Right, that's why I wrote with a bit more work. However, the nuance you 
mention doesn't seem to be present in the cover letter:
"This creates what we call "Software Enclaves", ensuring that an 
adversary with arbitrary code execution in the hypervisor STILL cannot 
read/write guest memory."
So if the end goal if really to protect against *all* sort of arbitrary 
code, then I think we should have a rough idea how this will look like 
in Xen.
From a brief look, it doesn't look like it would be possible to prevent 
modification to TTBR0_EL2 (even from EL3). We would need to investigate 
if there are other bits in the architecture to help us.
> Every little helps :-)
I can see how making the life of the attacker more difficult is 
appealing. Yet, the goal needs to be clarified and the risk with the 
approach acknowledged (see above).
Cheers,

--
Julien Grall