python api - segmentation fault

[hesengineering]

Environment

cat /etc/os-release | head -n 1
> PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"

python3 --version
> Python 3.7.3

pip3 list | grep cryptoauthlib
> cryptoauthlib   20210121

Script to reproduce

# print stack trace
# -------------------
import faulthandler;
faulthandler.enable()
# -------------------

while (True):

  from cryptoauthlib import *
  from cryptoauthlib.device import *
  
  load_cryptoauthlib()
  
  configuration = cfg_ateccx08a_i2c_default()
  configuration.cfg.atcai2c.bus = 1
  configuration.cfg.atcai2c.slave_address = 0x6A
  atcab_init(configuration)
  
  data = bytearray([0x01,0x02,0x03])
  cmac = bytearray(16)
  
  ctx = atca_aes_cmac_ctx()
  atcab_aes_cmac_init(ctx, 9, 1)
  atcab_aes_cmac_update(ctx, data, len(data))
  atcab_aes_cmac_finish(ctx, cmac, len(cmac))
  
  print(cmac.hex())

Error description

A segmentation fault error is thrown at a certain (random) point of the execution.

bce91efcbaef5a51be48987222f85ded
bce91efcbaef5a51be48987222f85ded
bce91efcbaef5a51be48987222f85ded
bce91efcbaef5a51be48987222f85ded
bce91efcbaef5a51be48987222f85ded
Fatal Python error: Segmentation fault

Additional notes

Script was running properly since I was using version 20200208.
I can confirm the bug is also present with version 20201130.

[bryan-hunt]

The call to load_cryptoauthlib is superfluous as it is handled by the import of cryptoauthlib. I did reproduce the above random failures on a pi3 with the same environment. When I removed the call to load_cryptoauthlib I did not encounter errors for the several minutes I let the script run

[bryan-hunt]

I've added a documentation task to remove references for load_cryptoauthlib - load_cryptoauthlib wasn't meant to be a risky call but since its apparent that there is something going on behind the scenes with the way ctypes loads the library that repeated calls stack up and cause a failure.

[hesengineering]

Thanks for the prompt reply @bryan-hunt

I can confirm the script works properly after removing the load_cryptoauthlib() call.

Unluckily I've discovered the segmentation fault is still thrown when the script ends.

Here a new test script:

from cryptoauthlib import *
from cryptoauthlib.device import *

configuration = cfg_ateccx08a_i2c_default()
configuration.cfg.atcai2c.bus = 1
configuration.cfg.atcai2c.slave_address = 0x6A
atcab_init(configuration)
  
data = bytearray([0x01,0x02,0x03])
cmac = bytearray(16)

for _ in range(10):
  ctx = atca_aes_cmac_ctx()
  atcab_aes_cmac_init(ctx, 9, 1)
  atcab_aes_cmac_update(ctx, data, len(data))
  atcab_aes_cmac_finish(ctx, cmac, len(cmac))
  print(cmac.hex())

print("end")

If you run the script there is a high chance the segmentation fault is thrown after the end message

b0e91efcbaef5a51be48987222f85ded
b0e91efcbaef5a51be48987222f85ded
b0e91efcbaef5a51be48987222f85ded
b0e91efcbaef5a51be48987222f85ded
b0e91efcbaef5a51be48987222f85ded
b0e91efcbaef5a51be48987222f85ded
b0e91efcbaef5a51be48987222f85ded
b0e91efcbaef5a51be48987222f85ded
b0e91efcbaef5a51be48987222f85ded
b0e91efcbaef5a51be48987222f85ded
end
Segmentation fault

Moving ctx = atca_aes_cmac_ctx() outside the loop seems to reduce the chances of error.

I'm currently calling the atca_xxx functions from a Python rest webservice. Since every rest call is spawn in an isolated thread, the segmentation fault occurs immediately when the thread is disposed and the main process badly dies.

[bryan-hunt]

The root cause is a definition error for the ctypes structure atca_aes_cbc_ctx in this version of the library. You can see that atca_aes_cmac_ctx inherits from it. The definition should be:

class atca_aes_cbc_ctx(Structure):
    """AES CBC Context"""
    _fields_ = [("device", c_void_p),
                ("key_id", c_uint16),
                ("key_block", c_uint8),
                ("ciphertext", c_char*16)]

To work around this you can create your own definitions using the above, or use the previous version of the library that was working. We have an update coming next week so this will be included. Unfortunately this seems to be the result of a missing test.

[hesengineering]

Glad to hear it's going to be fixed in the next update.

Thanks again for the support.

[bryan-hunt]

v3.3.1 is now released