Re: [Xen-ia64-devel] [PATCH 0/23] [RFC] VTi domain save/restore

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

Thank you for comment.

On Fri, Oct 12, 2007 at 05:56:17PM +0200, tgingold@xxxxxxx wrote:
> > - RSE (both PV and HVM domain)
> >   The number of physical stacked general register(RSE.N_STACKED_PHYS)
> >   isn't virtualized. Guest OS utilizes it via PAL_RSE_INFO call.
> >   If the number of cpu where domain is saved/restored aren't same,
> >   what should be supposed to do?
> >   The SDM says only that the number is cpu implementation specific.
> >   So the easiest way is to refuse restore.
> >   Any thoughts/comments?
> Refuse restore by default but have a flag to force it ?

Hmm, I should have described expected results.
I concluded the followings from Xen code and Linux kernel code,
but with other OSes there would be similar issues.

- Xen VMM itself may panic when trying to run guest with illegal operation 
  fault.
  When RSE.N_STACKED_PHYS of saving CPU > RSE.N_STACKED_PHYS of restoring CPU
  This case can be detected to refuse restore.

- guest kernel may panic with illegal operation fault
  When RSE.N_STACKED_PHYS of saving CPU > RSE.N_STACKED_PHYS of restoring CPU

- infomation leak from guest kernel to user process
  When RSE.N_STACKED_PHYS of saving CPU < RSE.N_STACKED_PHYS of restoring CPU

- user processes or operators would be confused.
  RSE.N_STACKED_PHYS is exported via /proc/cpuinfo.
  user processes might use it.
  I don't know any concreate example, but it's possible in theory.
  e.g. thread libraly may allocate RBS based on it.
       (Fortunately glibc nptl doesn't)

-- 
yamahata

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel