[Verse-dev] 64-bit problems

[Emil Brink]

Samuel Siltanen wrote:
> On Mon, 3 Oct 2005, Emil Brink wrote:
> 
>> Oh. What platform is this? The code that tries to generate random
>> numbers "good enough" for encryption assumes that all non-Windows plat-
>> forms have a /dev/urandom from which we can read random bits. It just
>> needs more porting attention to handle different platforms better.
> 
> 
> It is Debian Linux and there is /dev/urandom. I haven't look at the code 
> which reads the bits, but does it assume something about the size of the 
> integers?

Not at that level, no. The code that does the reading looks like this:

void v_randgen_get(VRandGen *gen, void *bytes, size_t num)
{
	if(gen != NULL && bytes != NULL)
	{
		if(read(gen->fd, bytes, num) != num)
			fprintf(stderr, __FILE__ ": Failed to read %u bytes of random data from " SOURCE "\n", (unsigned int) num);
	}
}

It's an unformatted "bulk" reading of the required number of bytes, no
structure to them at all.

 > The strange thing is that the key is still generated and seems
> to work on later runs when the key is read from a file.

I think it just generates a worse key in that case. At least I hope
that is how it fails.

>>> vmlnode.c line 553)
[...]
> Obviously it is Monday morning. The filename should be xmlnode.c and the 
> line would look like this:
> 
> cmd = (int) *filter++;
> 
> I am not sure how this expression does what it should.

Here, 'filter' is a void **. Basically, it's a pointer into an array of
void *s, containing a filter definition. A filter is defined by a bunch
of "commands", the XMLNODE_AXIS_XXX and XMLNODE_FILTER_XXX symbols in the
XmlNodeFilter enum (xmlnode.h:33). The filter ends with XMLNODE_FILTER_ACCEPT.

A sample filter, the XPath equivalent of

'child::layers/layer-vertex-xyz[name="vertex"]' is expressed like so:

void *filter[] = {
	XMLNODE_AXIS_CHILDREN,
	XMLNODE_FILTER_NAME, "layers",
	XMLNODE_AXIS_CHILDREN,
	XMLNODE_FILTER_NAME, "layers",
	XMLNODE_AXIS_CHILDREN,
	XMLNODE_FILTER_NAME, "layer-vertex-xyz",
	XMLNODE_FILTER_ATTRIB_VALUE, "name", "vertex",
	XMLNODE_FILTER_ACCEPT
};

Basically, it's a super-simple subset of XPath, without the textual inter-
face since I didn't want to write a parser just for this. :) The above is
slightly more advanced than what is typically needed in the VML loader; the
loader does the parsing from various points down in the XML tree so it often
needs only look one level further down (the above looks two).

The code in question reads off one such void * value, increases 'filter' to
point at the next one (could be an argument in case the command uses one,
like with XMLNODE_FILTER_NAME for instance), and also casts the result to
integer type so the forthcoming switch() can inspect and execute it.

I'm not sure how to write that so that it doesn't generate a warning on
64-bit systems, really ... How silly. I'm pretty sure the code is safe
as written; the integers, although stored as void *s, are small (9 bits),
and it's only integers that are stored in pointers, not the other way
around. Ideas welcome.

[unpack failure; encryption broken?]
> Perhaps we can just live with that then.

I think that is all we can do at the moment, although I'm pretty sure it's
on Eskil's list of things that should be fixed, at some point. Please let
us/the list know if you have similar warnings from the network unpacker at
other times, though.

Regards,

/Emil