On Tue, Dec 13, 2022 at 11:05:49PM +0000, Julien Grall wrote:
> 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?

That’s up to Marek.  My understanding is that it would allow guests to
use SMT if (and only if) they do not rely on any form of in-guest
sandboxing (at least as far as confidentiality is concerned).  In Qubes
OS, most guests should satisfy this criterion.  The main exception are
guests that run a web browser or that use the sandboxed indexing
functionality of tracker3.  In particular, Marek’s builders and other
qubes that do CPU-intensive workloads could benefit significantly.

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

Any form of confidential computing requires that the OS be modified to
treat the devices (such as disk and network interfaces) that it receives
from the host as untrusted, so such modification will be needed anyway.
Therefore, this is not an obstacle.  Conversely, cases where modifying
the guest is not possible invariably consider the host to be trusted,
unless I am missing something.

In contexts where the host is trusted, and the goal is to e.g. get rid
of the hypervisor’s instruction emulator, one approach would be inject
some emulation code into the guest that runs with guest kernel
privileges and has full R/W over all guest memory.  The emulation code
would normally be hidden by second-level page tables, but when the
hypervisor needs to emulate an instruction, the hypervisor switches to a
second-level page table in which this code and its stack are visible.
The emulation logic then does the needed emulation and returns to the
hypervisor, without the guest ever being aware that anything unusual has
happened.  While the emulation logic runs in the guest, it is normally
hidden by second-level page tables, so even the guest kernel cannot
observe or tamper with it.

>  * What happen for emulated device?

Using emulated devices in a setup where the emulator is not trusted
makes no sense anyway, so I don’t think this question is relevant.  The
only reason to use emulated devices is legacy compatibility, and the
legacy OSs that require them will consider them to be trusted.
Therefore, relying on emulated devices would defeat the purpose.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab