[Xen-devel] [PATCH RFC v3 0/6] HVM x86 deprivileged mode summary

[Ben Catterall <Ben.Catterall@xxxxxxxxxx>]

Hi all,

I have now finished my internship at Citrix and am posting this final version of
my RFC series. I would like to express my thanks to all of those who have taken
the time to review, comment and discuss this series, as well as to my colleagues
who have provided excellent guidance and help. I have learned a great deal and
have greatly enjoyed working with all of you. Thank you.

Hopefully the series will be beneficial. I believe that it has shown that a
deprivileged mode in Xen is a possible and viable option, as long as performance
impact vs security is carefully considered on a case-by-case basis. The end of
this series contains an example of moving some of the vpic into deprivileged
mode which has allowed me to test and verify that the feature works. There are
enhancements and some clean up which is needed but, after that, the feature
could be deployed to HVM devices currently found in Xen such as the VPIC.

Patches one to four are (hopefully) now fairly stable. Patch 5 is the new
system call and deprivileged dispatch mode which is new to this series. Patch 6
is also new and is a demonstration of using this for the vpic and hass mainly
been used to test and exercise this feature.

As this patch series is in RFC, there are some debug printks which should be
removed when/if it leaves RFC but, they are useful in fixing the known issue so
I have left them in until that can be resolved.

There are some efficiency savings that can be made and an instance of a general
issue (detailed later) which will need to be addressed.

Many thanks once again,
Ben

TODOs
-----
There is a set of TODOs in this patch series, some issues in the later patches
which need addressing and some other considerations which I've summarised here.

Patch 1:
 - Consider hvm_deprivileged_map_* and an efficiency saving by mapping in larger
   pages. See the TODO at the top of the L4 version of this method.

Patch 2:
 - We have a much more heavyweight version of the deprivileged mode context
   switch after testing for AMD SVM found that this was necessary. However,
   the FPU is currently also saved and this may not be necessary. Consideration
   is needed to work out if we can cut this down even more.

Patch 4:
 - The watchdog timer is hooked currently to kill deprivileged mode operations
   that run for too long and is hardcoded to be at least one watchdog tick and
   at most two. This may want to be refined.

Patch 5:
 - Alias data for deprivileged mode. There is a large comment at the top of
   deprivileged_syscall.c which outlines considerations.
 - Check if we need to map_domain_page the pages when we do the copy in
   hvm_deprivileged_copy_data{to/from}
 - Check for unsigned integer wrapping on addition in
   hvm_deprivileged_copy_data_{to/from}
 - Move hvm_deprivileged_syscall into the syscall macro. It's a stub and
   unless extra code is needed there it can be folded into the macro.
 - Check maintainers' thoughts on the deprivileged mode function checks in
   hvm_deprivileged_user_mode. See the TODO comment.

Patches 5 & 6:
 - Fix/work around the GCC switch statement issue.


KNOWN ISSUES
------------
 - Page fault for vpic_ioport_write due to GCC switch statements placing the
   jump table in .rodata which is in the privileged mode area.

   This has been traced to the first of the switch statements in the function.
   Though other switches in that function may also be affected.
   Compiled using GCC 4.9.2-10.

   You can get the offset into this function by doing:
   (RIP - (depriv_vpic_ioport_write - __hvm_deprivileged_text_start))

   It appears to be a built-in default of GCC to put switch jump tables in
   .rodata or .text and there does not appear to be a way to change this
   (except to patch the compiler, though hopefully there _is_ another
   option I just haven't been able to find...). Note that GCC will not
   necessarily allocate jump tables for each switch statment, it appears to
   depends on a number of factors such as the optimiser, the number of cases,
   the type of the case, compiler version etc.

   Thus, when we relocate a deprivileged method containing code using a switch
   statement which GCC has created a jump table for, this leads to a page
   fault. This is because we have not mapped in the rodata section
   as we should not (depriv should not have access to it).

   A workaround would be to patch the generated assembly so that this table is
   moved into hvm_deprivileged.rodata. This can be done by adding,
   .section .hvm_deprivileged.rodata, around the generated table. We can then
   relocate this.

   Note that GCC is using RIP-relative addressing for this, so the offset
   of depriv .rodata to the depriv .text segment will need to be the same
   when it is mapped in.







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