[PATCH for-11.0.0] Fix include statement for u2f-emu.h

[Stefan Weil via qemu development <qemu-devel@nongnu.org>]

All examples on https://github.com/Agnoctopus/libu2f-emu/ don't
simply include u2f-emu.h without any added directory.

The additional include directory does not exist when libu2f
was built with meson.

It's up to pkgconfig to make sure that u2f-emu.h is found in any case.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
---

libu2f-emu seems to be unmaintained. There are no Debian/Ubuntu packages,
and I am afraid that it is also not part of the CI tests.

Should it be deprecated/removed?

I recently was asked by a user to add it to QEMU for Windows.
It seems to work basically, but the user also noticed some issues.

Regards
Stefan

Citing the user's feedback:

As promised, I have tested the u2f and so far, it works as expected.
However, I do have a few notes.

1)
If you send the u2f emulation a malformed USB HID packet either to the HID Control EP
or the HID Interrupt EP, it crashes QEmu. Windows will show the "busy" mouse cursor
for a few seconds and then it will shut down QEmu. I am guessing the u2f emulation
doesn't do much error checking on that part.

2)
There are two versions of the u2f, one dated 11/04/2017 and one dated 12/20/2023.
The emulation is for the later, not the former. There is enough of a difference that it
is not backward compatible. I wonder if a note can be placed in the documentation
that the emulation is for the version dated 12/20/2023.

old version (11/04/2017)
https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/

new version (12/20/2023)
https://fidoalliance.org/specs/u2f-specs-master/

3)
If I don't send a "challenge" request first, the u2f seems to still process a successful
transfer even though the CID value is invalid. I guess the emulation doesn't check
for a valid CID before processing the request. This is a huge security problem, though
only in emulation, not host related.

4) (not really a QEmu problem, but still worth mentioning)
The specs don't specifically state that each transaction must be only a 64-byte
USB transaction. For example, if you need to send a message that is two 64-byte packets,
you must send them as individual USB transactions. You cannot send a single 128-byte USB transaction.
After reading the specs a bit more, it is implied, but not directly specified.
It took me a little trial and error to figure this out. I had a message that was more
than 64 bytes and less than 128 bytes so I was sending a single 128-byte USB transaction.
The u2f emulation didn't like this and only works if I send two consecutive 64-byte USB transactions.

5)
I only used the following in my command line:

  -device u2f-emulated

I did not try the 'passthru' nor the two following examples from the QEmu documentation.

 -device u2f-emulated,dir=$dir
 -device u2f-emulated,cert=$DIR1/$FILE1,priv=$DIR2/$FILE2,counter=$DIR3/$FILE3,entropy=$DIR4/$FILE4

All in all, if you have a properly coded u2f driver, I believe the QEmu u2f emulation to work as expected.
However, it does need some error checking added.



 hw/usb/u2f-emulated.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/usb/u2f-emulated.c b/hw/usb/u2f-emulated.c
index 196d05a83a..b82a315019 100644
--- a/hw/usb/u2f-emulated.c
+++ b/hw/usb/u2f-emulated.c
@@ -31,7 +31,7 @@
 #include "hw/usb/usb.h"
 #include "hw/core/qdev-properties.h"
 
-#include <u2f-emu/u2f-emu.h>
+#include <u2f-emu.h>
 
 #include "u2f.h"
 
-- 
2.47.3