@@ -47,7 +47,7 @@ let mark_as_bad con =
let initial_next_tid = 1
-let reconnect con =
+let do_reconnect con =
Xenbus.Xb.reconnect con.xb;
(* dom is the same *)
Hashtbl.clear con.transactions;
@@ -53,6 +53,10 @@ let end_transaction txn con tid commit =
trim ~txn ();
success
+let reconnect con =
+ trim ();
+ Connection.do_reconnect con
+
let push (x: history_record) =
let dom = x.con.Connection.dom in
match dom with
@@ -705,7 +705,7 @@ let do_input store cons doms con =
Connection.do_input con
with Xenbus.Xb.Reconnect ->
info "%s requests a reconnect" (Connection.get_domstr con);
- Connection.reconnect con;
+ History.reconnect con;
info "%s reconnection complete" (Connection.get_domstr con);
false
| Failure exp ->
@@ -744,7 +744,7 @@ let do_output _store _cons _doms con =
ignore (Connection.do_output con)
with Xenbus.Xb.Reconnect ->
info "%s requests a reconnect" (Connection.get_domstr con);
- Connection.reconnect con;
+ History.reconnect con;
info "%s reconnection complete" (Connection.get_domstr con)
)
There is a global history, containing transactions from the past 0.05s, which get trimmed whenever any transaction commits or aborts. Destroying a domain will cause xenopsd to perform some transactions deleting the tree, so that is fine. But I think that a domain can abuse the xenbus reconnect facility to cause a large history to be recorded - provided that noone does any transactions on the system inbetween, which may be difficult to achieve given squeezed's constant pinging. The theoretical situation is like this: - a domain starts a transaction, creates as large a tree as it can, commits it. Then repeatedly: - start a transaction, do nothing with it, start a transaction, delete part of the large tree, write some new unique data there, don't commit - cause a xenbus reconnect (I think this can be done by writing something to the ring). This causes all transactions/watches for the connection to be cleared, but NOT the history, there were no commits, so nobody trimmed the history, i.e. it the history can contain transactions from more than just 0.05s - loop back and start more transactions, you can keep this up indefinitely without hitting quotas Now there is a periodic History.trim running every 0.05s, so I don't think you can do much damage with it. But lets be safe an trim the transaction history anyway on reconnect. Signed-off-by: Edwin Török <edvin.torok@citrix.com> --- Changed since V1: * post publicly now that the XSA is out (not a security issue) --- tools/ocaml/xenstored/connection.ml | 2 +- tools/ocaml/xenstored/history.ml | 4 ++++ tools/ocaml/xenstored/process.ml | 4 ++-- 3 files changed, 7 insertions(+), 3 deletions(-)