WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [PATCH 0/6] trace: miscellaneous fixes

After getting a report of 3.2.3's xenmon crashing Xen (as it turned out
this was because c/s 17000 was backported to that tree without also
applying c/s 17515), this is the result of reviewing the code for
security issues:
- the hypervisor should not rely on any specific state of the actual
  trace buffer (as it is shared writable with Dom0)
- there's no need to share writably the t_info pages (Dom0 only wants
  [and needs] to read it)
- T_INFO_FIRST_OFFSET wasn't defined correctly, thus allowing in the
  num_online_cpus() == NR_CPUS case to pass a corrupted MFN to Dom0
- check_tbuf_size() didn't consider the case of the incoming size not
  allowing for the 2*data_size range for t_buf->{prod,cons}
- printk()-s should be lower level or rate limited

For the first of those items, I chose to use 'volatile' qualifiers
rather than sprinkling around barriers - this can certainly be changed
if considered unacceptable.

To make clear what purpose specific variables have and/or where they
got loaded from, the patch also changes the type of some of them to
be explicitly u32/s32, and removes pointless assertions (like checking
an unsigned variable to be >= 0).

I also took the prototype adjustment of __trace_var() as an opportunity
to simplify the TRACE_xD() macros. Similar simplification could be done
on the (quite numerous) direct callers of the function.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>


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

<Prev in Thread] Current Thread [Next in Thread>