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

[Richard W.M. Jones]

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
>      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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070323/b54501c4/attachment-0001.bin>