It's interesting to note what SunRPC gives you over XDR (which you have also noted in your emails):
- serial numbers to correlate client requests and server responses (in SunRPC these are called 'XID's)
- program numbers and versioning
- procedure numbers (same as your qemud_packet_{client,server} _data_type)
In fact the header of the SunRPC request and reply is just an
XDR-encoded data structure looking like this:
struct rpc_msg {
u_long rm_xid; // XID
// 0 = CALL, 1 = REPLY
enum msg_type rm_direction;
union {
struct call_body RM_cmb;
struct reply_body RM_rmb;
} ru;
};
struct call_body {
u_long cb_rpcvers; // always 2
u_long cb_prog; // program number
u_long cb_vers; // program version
u_long cb_proc; // procedure number
struct opaque_auth cb_cred; // credentials - ignore
struct opaque_auth cb_verf; // verifier - ignore
};
struct reply_body is a bit more complex - see <rpc/rpc_msg.h>.
Actually there are functions provided to generate the call and reply
headers (xdr_callhdr and xdr_replymsg) so we could use those directly to
create SunRPC-compatible headers. Advantages: Wire sniffing tools
which grok SunRPC will still work (Wireshark does NFS, so presumably it
does general Sun/ONC-RPC; Systemtap apparently supports it too). There
are various other efforts to run SunRPC over TLS (including an OCaml
one!) which we may still be able to interoperate with.
In addition we have provided encryption and authentication. Your patch punts on that - I understand why.
About strings: char foo[MAX] (as you pointed out) could be replaced by variable-length strings. There are at least three catches: (1) Who owns/frees the strings? - I was never able to work that out. (2) NULL is not supported directly, you have to use the option-looks-like- a-pointer type (string *). (3) If the client and server don't trust each other then you need to check the length of incoming strings carefully to make sure that they aren't huge and potentially could cause a DoS.
1. Add an extra initial message type to do a major/minor version number
exchange. Based on the negotiated versions, the server can activate
or deactivate particular requests it allows from the client.
2. Add in the URI parsing routines to the qemud_interal.c driver, but
only allow use of QEMU initially.
3. Add in the TLS + SSH client & server socket setup code to give an
authenticated & secured remote channel
4. Re-factor qemud/dispatch.c so that it calls into the regular libvirt
API for the Xen case, but keeps calling qemud/driver.c for the QEMU
case.
You'd definitely want to call it something other than 'qemu' ... Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature