| commit | de2cad7a8c2718d22f23a72d30c6cf5bc27a35b5 | [log] [tgz] |
|---|---|---|
| author | Will Drewry <wad@google.com> | Fri Mar 10 15:53:34 2017 -0600 |
| committer | Will Drewry <wad@google.com> | Fri Mar 10 15:54:50 2017 -0600 |
| tree | 4bfa91430becfcb6c294129483908278587570a9 | |
| parent | 4aa454a96f80ba674e3f887bc07520b5f5cfebe2 [diff] |
Clean up and refactor; new hw support (Originally, https://android-review.googlesource.com/#/c/341550/) This change addresses portability, a pn80t platform abstraction, and nq-nci support. Refactor/clean up: - Adds darwin-sysdeps.c to help avoid reverting again. - Clean up Android.bp - T=1: moved T=1 to using bit_specs to keep some of the readability of bitfields without incurring weird toolchain side effects. - T=1 will still rely on compilers keeping uchars aligned and check it with a div-by-zero build assertion. - ESE platform specific methods are now wrapped. - Adjusted error message constant usage. - Enclosing {} for every if statement. - Moved to relative headers for inclusion into other code bases. - Added a comment to log.h to make debugging easier globally in libese code. PN80T: - Common code now shared across different wire configurations. - Add support for kernel based driver (called nq-nci) which interacts with the nq-nci behavior for power management. - Added cooldown/end of session code to pn80t/common.c - Migrated the ese_nxp_sample code to NQ_NCI and added the empty session to test the cooldown code submission. Bug: 34193473,35105409 Change-Id: I8fc320c8c236282ed103ef3ee3cb8c0dc99d8bcb Test: unittests pass, tested ese-relay on hardware forwarding globalplatform pro
Document last updated: 13 Jan 2017
libese provides a minimal transport wrapper for communicating with embedded secure elements. Embedded secure elements typically adhere to smart card standards whose translation is not always smooth when migrated to an always connected bus, like SPI. The interfaces exposed by libese should enable higher level “terminal” implementations to be written on top and/or a service which provides a similar interface.
Behind the interface, libese should help smooth over the differences between eSEs and smart cards use in the hardware adapter implementations. Additionally, a T=1 implementation is supplied, as it appears to be the most common wire transport for these chips.
Public client interface for Embedded Secure Elements.
Prior to use in a file, import all necessary variables with:
ESE_INCLUDE_HW(SOME_HAL_IMPL);
Instantiate in a function with:
ESE_DECLARE(my_ese, SOME_HAL_IMPL);
or
struct EseInterface my_ese = ESE_INITIALIZER(SOME_HAL_IMPL);
or
struct EseInterface *my_ese = malloc(sizeof(struct EseInterface)); ... ese_init(my_ese, SOME_HAL_IMPL);
To initialize the hardware abstraction, call:
ese_open(my_ese);
To release any claimed resources, call
ese_close(my_ese)
when interface use is complete.
To perform a transmit-receive cycle, call
ese_transceive(my_ese, ...);
with a filled transmit buffer with total data length and an empty receive buffer and a maximum fill length. A negative return value indicates an error and a hardware specific code and string may be collected with calls to
ese_error_code(my_ese); ese_error_message(my_ese);
The EseInterface is not safe for concurrent access. (Patches welcome! ;).
libese is broken into multiple pieces:
libese provides the headers and wrappers for writing libese clients and for implementing hardware backends. It depends on a backend being provided as per libese-hw and on libese-sysdeps.
libese-sysdeps provides the system level libraries that are needed by libese provided software. If libese is being ported to a new environment, like a bootloader or non-Linux OS, this library may need to be replaced. (Also take a look at libese/include/ese/log.h for the macro definitions that may be needed.)
libese-hw provides existing libese hardware backends.
libese-teq1 provides a T=1 compatible transcieve function that may be used by a hardware backend. It comes with some prequisites for use, such as a specifically structured set of error messages and EseInteface pad usage, but otherwise it does not depends on any specific functionality not abstracted via the libese EseOperations structure.
There are two test backends, fake and echo, as well as one real backend for the NXP PN80T/PN81A.
The NXP backends support both a direct kernel driver and a Linux SPIdev interface.