Zymkey 4i Memory Leak

ZYMKEY4
1

I’m currently trying to use Zymkey on my Raspberry Pi which runs DietPi.
I tried integrating the C API into my application but it keeps giving me a segmentation fault.

I then compiled the following program using gcc -g -lzk_app_utils test.c

#include <zymkey/zk_app_utils.h>
void main()
{
zkCTX ctx;
zkOpen(&ctx);
zkClose(ctx);
}

I then ran the program using valgrind ./test.out

And I got the following results:
HEAP SUMMARY:
==2450== in use at exit: 472 bytes in 14 blocks
==2450== total heap usage: 89 allocs, 75 frees, 23,537 bytes allocated
==2450==
==2450== LEAK SUMMARY:
==2450== definitely lost: 40 bytes in 1 blocks
==2450== indirectly lost: 432 bytes in 13 blocks
==2450== possibly lost: 0 bytes in 0 blocks
==2450== still reachable: 0 bytes in 0 blocks
==2450== suppressed: 0 bytes in 0 blocks

Am I doing something wrongly or is there a problem with the library?

2

Thanks for pointing this out. We’ll be looking into it soon.

3

I have run your demo against valgrind on Raspbian Stretch and there are no leaks reported. My guess is that there might be a leak in one of the supporting libs in the DietPi distro.

==7685== Memcheck, a memory error detector
==7685== Copyright © 2002-2017, and GNU GPL’d, by Julian Seward et al.
==7685== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==7685== Command: ./test -v
==7685==
==7685==
==7685== HEAP SUMMARY:
==7685== in use at exit: 0 bytes in 0 blocks
==7685== total heap usage: 67 allocs, 67 frees, 22,655 bytes allocated
==7685==
==7685== All heap blocks were freed – no leaks are possible
==7685==
==7685== For counts of detected and suppressed errors, rerun with: -v
==7685== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 3)

4

Hi! Thanks for the reply.
DietPi is based off Raspbian Stretch so I believe the supporting libraries should more or less be the same.
Nevertheless, I’ll try to do more testing and see what I can find out.
I would need to use DietPi as my Operating System so switching to Raspbian would not be an option for me.
Thanks!

5

I’m running my application on a custom compiled kernel so I thought maybe that could have cause the problem. I tried running the same test application on a clean installation of DietPi and it gives me the same memory leak sometimes only. Like it seems to resolve itself after i systemctl restart zkifc

I ran my application using valgrind and gdb and got these results:
==1745== Thread 2:
==1745== Invalid read of size 1
==1745== at 0x484C43C: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==1745== Address 0x0 is not stack’d, malloc’d or (recently) free’d
==1745==
==1745==
==1745== Process terminating with default action of signal 11 (SIGSEGV)
==1745== Access not within mapped region at address 0x0
==1745== at 0x484C43C: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)

[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/arm-linux-gnueabihf/libthread_db.so.1”.
[New Thread 0x7638a370 (LWP 1900)]

Thread 2 “a.out” received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7638a370 (LWP 1900)]
__GI_strcmp (p1=, p2=) at strcmp.c:38
38 strcmp.c: No such file or directory.

(gdb) bt
#0 __GI_strcmp (p1=, p2=) at strcmp.c:38
#1 0x76fa3d00 in ?? () from /usr/lib/libzk_app_utils.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

There seems to be an issue when it strcmp. Is it perhaps checking for some config or version number which might be different in Raspbian and DietPi?

6

I checked the logs for zkifc and it shows the following

root@DietPi:~# journalctl -u zkifc
– Logs begin at Fri 2016-11-04 01:16:42 +08, end at Wed 2019-01-30 14:58:12 +08. –
Jan 30 01:41:16 DietPi systemd[1]: Starting Zymkey Interface Connector…
Jan 30 01:41:16 DietPi systemd[1]: Started Zymkey Interface Connector.
Jan 30 01:41:16 DietPi su[825]: Successful su for zymbit by root
Jan 30 01:41:16 DietPi su[825]: + ??? root:zymbit
Jan 30 01:41:16 DietPi su[825]: pam_unix(su:session): session opened for user zymbit by (uid=0)
Jan 30 14:58:03 DietPi su[825]: could not open stage 1 salt file
Jan 30 14:58:05 DietPi su[825]: could not open stage 1 salt file

What is this stage 1 salt file?

7

zkifc attempts to find the cpu serial number in /proc and the sd card cid in /sys. If those identifiers are not available, that could cause a problem.

8

The stage 1 salt file is something that also helps to uniquely identify the host to the zymkey. It lives in /var/lib/zymbit. Does that path exist in your installation?

9

i can confim that the serial number is present in /proc/cpuinfo
and the cid of the sd card is present in /sys/class/mmc_host/mmc0/mmc0:aaaa/cid
and that the /var/lib/zymbit path exists

10

What is in /var/lib/zymbit?

11

I did more testing and it seems that the problem arises from my custom compiled kernel.
I ran the program on a clean installation of DietPi and it works.
But after I replaced the kernel with my custom compiled one, it stops working and zkifc gives this message: Feb 05 12:13:51 DietPi su[748]: Failed to create bus connection: No such file or directory.
My compiled kernel is pretty much the default with the following extras enabled only:
Select Cryptographic API → CMAC support
Select Cryptographic API → User-space interface for hash algorithms
Select Cryptographic API → User-space interface for symmetric key cipher algorithms
I’ll try with a compiled vanilla kernel

12

I just tried with a compiled vanilla kernel and it works without any problems. That means that the problem is with my custom compiled kernel. But I do require the following functions to be enabled in the kernel as I’m using them for my bluetooth mesh network.
Select Cryptographic API → CMAC support
Select Cryptographic API → User-space interface for hash algorithms
Select Cryptographic API → User-space interface for symmetric key cipher algorithms

13

Make sure that you’ve enabled i2c bus support along with the i2c-dev driver.