homectl: make sure we sent the full 8 bytes as flags

[mrc0mmand]

Otherwise weird stuff happens on the other side:

[1217111.957263] testsuite-46.sh[61]: + homectl create test-user --disk-size=min --luks-discard=yes --image-path=/home/test-user.home --luks-pbkdf-type=pbkdf2 --luks-pbkdf-time-cost=1ms
[1217112.598219] homectl[66]: Operation on home test-user failed: Provided flags are unsupported (0ad2578000000000).

(taken from TEST-46-HOME run on armv7l)

Fixes issue mentioned in #31419 (comment).

[bluca]

Wait, what? We have tons of flags parameters, does that mean most of those are sending broken messages?

[mrc0mmand]

Wait, what? We have tons of flags parameters, does that mean most of those are sending broken messages?

If there's a 0 constant together with "t" type, then it's possible, see also c63bfd0.

[bluca]

Shouldn't the library cast any 't' input automatically then, rather than having every caller do it?

[AdrianVovk]

When we see t we know we must read 8 bytes out of the next argument. The problem is that we've passed in 4, but the function being called has no way of knowing that b/c of the vararg. So ultimately it's reading the 4 bytes we passed in w/ 4 bytes of junk. The function being called has no way to detect this or fix it

[mrc0mmand]

Yup, as Adrian says, this is an unfortunate (mis?) feature of the va_arg stuff. For example, with this reproducer:

#include <stdarg.h>
#include <stdint.h>
#include <stdio.h>

void vaarg_fun(const char *types, ...) {
        va_list ap;

        va_start(ap, types);
        printf("0x%llx\n", va_arg(ap, uint64_t));
        va_end(ap);
}

int main(void) {
        vaarg_fun("t", 0);
        vaarg_fun("t", UINT64_C(0));
        vaarg_fun("t", 1);
        vaarg_fun("t", UINT64_C(1));
        return 0;
}

I get this output on x86_64:

$ ./test 
0x0
0x0
0x1
0x1

But on armv7l I get this:

$ ./test 
0x4007e4bed77dfc
0x0
0x4007e400000000
0x1

Maybe I should, at least, write a Coccinelle rule, that would catch these cases somewhat automagically.

[poettering]

also see → #31427

[bluca]

Maybe I should, at least, write a Coccinelle rule, that would catch these cases somewhat automagically.

That would be very nice, because this is not at all obvious otherwise