c72be5dd2f
riscv32 is (surprise!) a 32-bit architecture. But it has been Y2038-safe
from its inception. As such, there are no legacy binaries that may use
the 32-bit time syscalls, and thus they are not available on riscv32.
Code that directly calls to the syscalls without using the C libraries
wrappers thus need to handle this case by themselves. That's what
upstream tried to do with:
5b5e2985f3
We initially carried that patch with 2bb26c1a1d (package/libopenssl:
fix build on riscv32).
However, as Arnd Bergmann puts it [0]:
The patch looks wrong to me: __NR_io_pgetevents_time64 must be used
whenever time_t is 64-bit wide on a 32-bit architecture, while
__NR_io_getevents/__NR_io_pgetevents must be used when time_t is the
same width as 'long'.
Checking whether __NR_io_getevents is defined is wrong for all
architectures other than riscv
And Arnd agrees that patch should be reverted [1] [2] (there are further
comments in that stream, that are worth reading).
As such, we've reverted 2bb26c1a1d with 6cfb4ad7f7.
This means we have no working solution to enable openssl on riscv32 for
now. So, rather than fail the build, or backport a dysfunctional patch,
let's just forbid openssl on riscv32.
Drop the default from the choice selection; it was anyway superfluous:
the default of a choice, if left unspecified, is the first entry of the
choice. Also, having a default means we'd have to also propagate the
dependencies of the defaulted-to symbol, which is yet a little bit more
maintenance. Since the chances we get a third implementation of openssl
are pretty slim (very, very slim), reasoning about what is the default
is still very easy.
When propagating dependencies to tpm2-tss' users, we've tried to keep
the architecture dependency toward the top when possible, and otherwise
we've added it together with existing arch dependencies (MMU).
While at it, drop a useless redundant comment in ibm-sw-tpm2: if we
select FORCE_LIBOPENSSL, it is obvious that's because libressl is not
supported... Besides none of the other users of FORCE_LIBOPENSSL have
such a comment.
Fixes:
http://autobuild.buildroot.org/results/eb9/eb9a64d4ffae8569b5225083f282cf87ffa7c681/
...
http://autobuild.buildroot.org/results/07e/07e413b24ba8adc9558c80267ce16dda339bf032/
[0] 5b5e2985f3 (commitcomment-44782859)
[1] 5b5e2985f3 (commitcomment-47826509)
[2] 5b5e2985f3 (commitcomment-47830530)
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Mark Corbin <mark@dibsco.co.uk>
61 lines
2.5 KiB
Plaintext
61 lines
2.5 KiB
Plaintext
config BR2_PACKAGE_TPM2_TSS
|
|
bool "tpm2-tss"
|
|
depends on !BR2_STATIC_LIBS # dlfcn.h
|
|
depends on BR2_PACKAGE_LIBOPENSSL_ARCH_SUPPORTS
|
|
select BR2_PACKAGE_LIBURIPARSER
|
|
select BR2_PACKAGE_OPENSSL
|
|
select BR2_PACKAGE_OPENSSL_FORCE_LIBOPENSSL
|
|
help
|
|
OSS implementation of the Trusted Computing Group's (TCG) TPM2
|
|
Software Stack (TSS). This stack consists of the following
|
|
layers from top to bottom:
|
|
|
|
* System API (SAPI) as described in the system level API and
|
|
TPM command transmission interface specification. This API
|
|
is a 1-to-1 mapping of the TPM2 commands documented in Part
|
|
3 of the TPM2 specification. Additionally there are
|
|
asynchronous versions of each command. These asynchronous
|
|
variants may be useful for integration into event-driven
|
|
programming environments. Both the synchronous and
|
|
asynchronous API are exposed through a single library:
|
|
libtss2-sys.
|
|
|
|
* TPM Command Transmission Interface (TCTI) that is described
|
|
in the same specification. This API provides a standard
|
|
interface to transmit / receive TPM command / response
|
|
buffers. It is expected that any number of libraries
|
|
implementing the TCTI API will be implemented as a way to
|
|
abstract various platform specific IPC mechanisms. Currently
|
|
this repository provides two TCTI implementations:
|
|
libtss2-tcti-device and libtss2-tcti-mssim. The prior should
|
|
be used for direct access to the TPM through the Linux
|
|
kernel driver. The later implements the protocol exposed by
|
|
the Microsoft software TPM2 simulator.
|
|
|
|
https://github.com/tpm2-software/tpm2-tss
|
|
|
|
if BR2_PACKAGE_TPM2_TSS
|
|
|
|
config BR2_PACKAGE_TPM2_TSS_FAPI
|
|
bool "fapi support"
|
|
depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c
|
|
select BR2_PACKAGE_JSON_C
|
|
select BR2_PACKAGE_LIBCURL
|
|
help
|
|
This option allows to enable Feature API (FAPI). Feature
|
|
API (FAPI) as described in the "TSS 2.0 Feature API
|
|
Specification" along with "TSS 2.0 JSON Data Types and
|
|
Policy Language Specification" This API is designed to be
|
|
very high-level API, intended to make programming with the
|
|
TPM as simple as possible. The API functions are exposed
|
|
through a single library: libtss2-fapi.
|
|
|
|
https://trustedcomputinggroup.org/wp-content/uploads/TSS_FAPI_v0.94_r04_pubrev.pdf
|
|
https://trustedcomputinggroup.org/wp-content/uploads/TSS_JSON_Policy_v0.7_r04_pubrev.pdf
|
|
|
|
endif
|
|
|
|
comment "tpm2-tss needs a toolchain w/ dynamic library"
|
|
depends on BR2_PACKAGE_LIBOPENSSL_ARCH_SUPPORTS
|
|
depends on BR2_STATIC_LIBS
|