Workaround patch

[NikoDelarich]

Hi,

I'm currently porting the Linux PAL to my platform and was wondering about the workaround patch for pal_os_event.c. As far as I could understand, the patch adds three new functions (arm, disarm & destroy1) which are then called by the trustm_engine if WORKAROUND is defined. pal_os_event_arm: Wind up the timer to fire initially after 1ms & then periodically every ~294ms (294967296ns which may be a typo & should actually be UINT32_MAX + 1?). pal_os_event_disarm: Disarm the timer pal_os_event_destroy1: Delete the timer

Could you explain the reason for this workaround?

Thanks!

[tim20190215]

[tim20190215]

If you enable the debug "#define TRUSTM_PAL_EVENT_DEBUG = 1" in pal_os_event.c and run the CLI trustm_chipinfo you will see the timer continue to runs even after the programs completed (see attachment above). This post problem when running it on OpenSSL engine where it either cause the OpenSSL engine to hang or segmentation fault occurs. Hence the workaround is it used in the trustm_engine whenever the api is completed disarm the timer and rearm again before calling the api. Hope this helps.

[pwiegele]

@NikoDelarich does this answer your question? Can we close the issue?

[NikoDelarich]

Sorry for the late reply. Well, partially. I suppose this is for applications that want to use both the trustm_library directly & the trustm_engine in OpenSSL?

We link our application with the trustm-library as well as the trustm_engine (indirectly over openssl) and we need to be able to communicate with the chip over the trustm_library directly (e.g. to read out the device certificate) as well as using the trustm_engine to communicate with the Optiga Trust-M. We managed to get it working (without the workaround patch) sequentially (i.e. we first read the certificate using the trustm_library an afterwards we initialize the trustm_engine) but in the future we may need to get it working with multiple trustm_lib-instances at the same time.

The trustm_lib seems to support multiple instances (all sharing the same comms-layer instance) but I haven't found any sample code to demonstrate this - is this supported? Or is the workaround supposed to make this possible?

[pwiegele]

Hi NikoDelarich,

have a look at the branch here. This branch brings experimental support for two processes which are using our library at the same time. Let me know if it helps.

[NikoDelarich]

Thanks for the link - that looks very interesting! We'll definitely need something like this in the future if we want multiple processes to be able to access the secure element simultaneously.