Re: [libvirt] [PATCH] tests: qemu: mock master key generation
On 05/11/2016 08:49 AM, Peter Krempa wrote:
On Wed, May 11, 2016 at 07:53:07 -0400, John Ferlan wrote:
>
>
> On 05/11/2016 07:36 AM, Peter Krempa wrote:
>> The master key generation is using host state to get the random bytes.
>> Currently it's not used so it doesn't break any tests, but it may become
>> a problem in the future.
>>
>> Fix it by mocking qemuDomainGenerateRandomKey. This is possible after
>> exporting it and switching to the dynamically linked qemu driver object
>> for tests.
>> ---
>> This also makes the test not call any gnutls function which crashed certain
>> gnutls versions as we did not initialize it (gnutls_global_init()). It may be
>> also worth adding the call to virtTestMain so that tests don't run into that
>> problem, but I'm not totaly persuaded that it's a good idea.
>>
>> src/qemu/qemu_domain.c | 2 +-
>> src/qemu/qemu_domain.h | 2 ++
>> tests/Makefile.am | 2 +-
>> tests/qemuxml2argvmock.c | 21 +++++++++++++++++++++
>> 4 files changed, 25 insertions(+), 2 deletions(-)
>>
>
> I think I addressed this in patch 2 of my series:
>
> http://www.redhat.com/archives/libvir-list/2016-May/msg00444.html
I didn't notice it since it was together with other stuff. I've reviewed
that series. Looking at the code I think this patch is a bit cleaner
than the approach used in the linked patch.
IDC either way for the implementation... It'll adjust my series insomuch
as I the 'answer' I expect in the .args file for the 'iv' and encoded
masterKey, but I can deal with that.
One reason I mocked virRandomBytes was based on suggestion, but also
because it was used by virUUIDGenerate and that could mean we can
generate output xml/args from input that doesn't have a uuid since we
can predict the answer.
Also, "theoretically speaking" virStorageGenerateQcowPassphrase could
call virRandomBytes (with a couple of adjustments) instead of going to
/dev/urandom... Anything in the future which may use virRandomBytes
could also get predictable answers (while it's not written now, I'm
thinking the changes that would support luks may find it useful).
Basically, anything else that needs to perhaps get a "random" string of
bytes could then get predictable answers if virRandomBytes is changed.
I'm OK with this method, although I am wondering if it would be better
to mock virRandomBytes instead?
John
Additionally this also switches right away to the shared object qemu
driver which allows to mock functions in the qemu driver directly.
Peter