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

Re: [Libvir] RFC [0/3]: Re-factor QEMU daemon protocol to use XDR

As you say, no appreciable difference in code side before and after the change.

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

You'd definitely want to call it something other than 'qemu' ...


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

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