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

[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


 


Rackspace

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