Re: [Libguestfs] [nbdkit PATCH] filters: Bump API version

On 8/27/19 7:27 AM, Richard W.M. Jones wrote: We could s/int _api_version/char *_api_string/ (which is itself an API-incompatible change). Doing so makes it that much tighter that you have to run a filter from the same version as nbdkit (whereas our current API check allows running 1.13.1 nbdkit with 1.13.2 filter or vice-versa, and that may not always be accurate). Historically, we began filters with API version 1 (not 0), which works to our advantage: all released nbdkit are looking for filters in the range [1,5). ABI-wise, there are four cases to consider: 32-bit pointer, little-endian: no compiler puts a string constant in the first page of memory, so any string pointer will be much larger than 5 and therefore show up as incompatible to older nbdkit. Newer nbdkit will have to be careful to not dereference a char* until first validating that interpreting it as an int looks like a reasonable pointer. 64-bit pointer, little-endian: the first four bytes of any pointer are the least significant; a compiler _could_ place the string constant of a new filter at 0x100000004 which would look like API version 4 to old nbdkit; so we get further in attempting to use the mismatched version. Conversely, new nbdkit loading an old filter has to do the pre-screen to attempt to not dereference a pointer where the first 4 bytes look like a small integer; and this could mean nbdkit fails to load a new filter where the compiler placed the version string at 0x100000004. But this placement is corner-case enough (depends on a platform ABI where the memory map places read-only portions of the binary above 4G even when the binary itself is not that large), so I don't think we need to worry about it. 32-bit pointer, big-endian: similar story to little-endian; we can tell whether the 4 bytes looks like a small integer or a valid pointer. 64-bit pointer, big-endian: the first four bytes of a pointer are likely to be 0x00000000 (unless a compiler places read-only memory above 4G); and since 0 is not a valid API version, old nbdkit will reject new filters; new nbdkit can check if the first four bytes are 0 (assume pointer) or small integer (reject old filter). The goal here is some basic sanity checking; if a user mismatches versions, they are already using nbdkit incorrectly, so if it crashes instead of giving graceful failure, there's not much we can do about it. The sanity checking will work most of the time, however, giving us graceful failure. I'll post a patch along those lines shortly. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org