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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 15 Dec 2022, 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.
> > > 
> > > > My team at Riverside Research is currently spending IRAD funding to
> > > > prototype next-generation secure hypervisor design ideas on Xen. In
> > > > particular, we are prototyping the idea of Virtual Memory Fuses for
> > > > Software Enclaves, as described in this paper:
> > > > https://www.nspw.org/papers/2020/nspw2020-brookes.pdf. Note
> > > that that
> > > > paper talks about OS/Process while we have implemented the idea
> > > for
> > > > Hypervisor/VM.
> > > > 
> > > > Our goal is to emulate something akin to Intel SGX or AMD SEV, but
> > > > using only existing virtual memory features common in all
> > processors.
> > > > The basic idea is not to map guest memory into the hypervisor so
> > > that
> > > > a compromised hypervisor cannot compromise (e.g. read/write) the
> > > > guest. This idea has been proposed before, however, Virtual Memory
> > > > Fuses go one step further; they delete the hypervisor's mappings to
> > > > its own page tables, essentially locking the virtual memory
> > > > configuration for the lifetime of the system. This creates what we
> > > > call "Software Enclaves", ensuring that an adversary with arbitrary
> > > > code execution in the hypervisor STILL cannot read/write guest
> > > memory.
> > > 
> > > I am confused, if the attacker is able to execute arbitrary code, then
> > > what prevent them to write code to map/unmap the page?
> > > 
> > > Skimming through the paper (pages 5-6), it looks like you would need
> > > to implement extra defense in Xen to be able to prevent map/unmap a
> > > page.
> > > 
> > 
> > The key piece is deleting all virtual mappings to Xen's page table
> > structures. From the paper (4.4.1 last paragraph), "Because all memory
> > accesses operate through the MMU, even page table memory needs
> > corresponding page table entries in order to be written to." Without a
> > virtual mapping to the page table, no code can modify the page table
> > because it cannot read or write the table. Therefore the mappings to the
> > guest cannot be restored even with arbitrary code execution.
>
> I don't think this is sufficient. Even if the page-tables not part of the
> virtual mapping, an attacker could still modify TTBR0_EL2 (that's a system
> register hold a host physical address). So, with a bit more work, you can gain
> access to everything (see more below).
> 
> AFAICT, this problem is pointed out in the paper (section 4.4.1):
> 
> "The remaining attack vector. Unfortunately, deleting the page
> table mappings does not stop the kernel from creating an entirely
> new page table with the necessary mappings and switching to it
> as the active context. Although this would be very difficult for
> an attacker, switching to a new context with a carefully crafted
> new page table structure could compromise the VMFE."
> 
> I believe this will be easier to do it in Xen because the virtual layout is
> not very complex.
> 
> It would be a matter of inserting a new entry in the root table you control. A
> rough sequence would be:
>    1) Allocate a page
>    2) Prepare the page to act as a root (e.g. mapping of your code...)
>    3) Map the "existing" root as a writable.
>    4) Update TTBR0_EL2 to point to your new root
>    5) Add a mapping in the "old" root
>    6) Switch to the old root
> 
> So can you outline how you plan to prevent/mitigate it?

[...]

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

Every little helps :-)