qrexec messages should be chunked

[reynir]

I discovered that messages sent to a qrexec-client-vm were dropped if the message (without header I believe) was more than 4096 bytes long. I spoke with marmarek about this, and was told that longer messages should be split into chunks and sent separately. Furthermore, I was told that you should check if there was space to write before writing the header; otherwise a deadlock could occur because while waiting for more buffer space the other end would wait for the rest of the message. I haven't figured out how to do that in OCaml.

I intend to implement this myself, but I'm stuck and don't have much time lately.

[talex5]

This is specifically for the qrexec protocol?

I guess you just need to check the length in
https://github.com/mirage/mirage-qubes/blob/master/lib/rExec.ml#L37
and split it if longer than 4096.

[reynir]

I'm not sure. The qrexec code rejecting longer messages is here. The MAX_DATA_CHUNK constant is defined here. When grepping for MAX_DATA_CHUNK in my local copy of all QubesOS repos I only get results for qrexec, so it could be it's qrexec specific.

Would that handle vchan buffer space? Here's how qrexec checks.

I could implement that as a first approximation at least, and then worry about checking space later.

[talex5]

Well, their API is:

• You provide an input stream and it copies some of the input to the vchan without blocking. It therefore cares about how much space is available. The caller has to detect when more space is available and call it again until all the data is sent.

Our API is:

• You provide a string and it transmits all the data when space is available, returning a promise to indicate when it is complete.

It might be more efficient to chunk the data according to the free space, but I suspect it makes little difference.

[reynir]

I've implemented a first approximation here https://github.com/reynir/mirage-qubes/tree/chunking. I'm not 100% what to do in case `Eof` is returned. The implementation returns Eof and drops any remaining data not sent yet.

I have tested it with reynir/qubes-mirage-ssh-agent#1 and I can now add 30 keys without a problem.

[talex5]

That looks right to me.