[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC 4/4] HVM x86 deprivileged mode: Trap handlers for deprivileged mode





On 06/08/15 22:24, Andrew Cooper wrote:
On 06/08/2015 17:45, Ben Catterall wrote:
Added trap handlers to catch exceptions such as a page fault, general
protection fault, etc. These handlers will crash the domain as such exceptions
would indicate that either there is a bug in deprivileged mode or it has been
compromised by an attacker.

Signed-off-by: Ben Catterall <Ben.Catterall@xxxxxxxxxx>
---
  xen/arch/x86/mm/hap/hap.c |  9 +++++++++
  xen/arch/x86/traps.c      | 41 ++++++++++++++++++++++++++++++++++++++++-
  2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index abc5113..43bde89 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -685,8 +685,17 @@ static int hap_page_fault(struct vcpu *v, unsigned long va,
  {
      struct domain *d = v->domain;
+ /* If we get a page fault whilst in HVM security user mode */
+    if( v->user_mode == 1 )
+    {
+        printk("HVM: #PF (%u:%u) whilst in user mode\n",
+                 d->domain_id, v->vcpu_id);
%pv is your friend.  Like Linux, we have custom printk formats.  In this
case, passing 'v' as a parameter to %pv will cause d$Xv$Y to be
printed.  (The example below predates %pv being introduced).
ok, will do. thanks!

+        domain_crash_synchronous();
No need for _synchronous() here.  _synchronous() should only be used
when you can't safely recover.  It ends up spinning in a tight loop
waiting for the next timer interrupt, is anything up to 30ms away.
I'm not sure if we can safely recover from this. This will only be triggered if there is a bug in depriv mode or if the mode has been compromised and an attacker has tried to access unavailable memory. From my understanding (am I missing something?): domain_crash effectively sets flags to tell the scheduler that it should be killed the next time the scheduler runs and then returns. In which case, if we don't do a synchronous crash, this return path would return back into the deprivileged mode, we would not
have mapped in the page (as we shouldn't), and then we get another fault.

What do you think is the best way forward? Thanks!


~Andrew

+    }
+
      HAP_ERROR("Intercepted a guest #PF (%u:%u) with HAP enabled.\n",
                d->domain_id, v->vcpu_id);
+
      domain_crash(d);
      return 0;
  }


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.