* Supports sending memfds in addition to data from an iovec
* Also add a basic test called send-fd
Bug: 117221195
Test: Run send-fd with corresponding Trusty application.
Change-Id: I562d2ff744938c868323a016659ca1332f6a576b
The mock RPMB can get out of sync with TD storage blocks in the event of
panic or crash. Making this O_SYNC will prevent this from happening.
Bug: 160723681
Test: None
Change-Id: Ia16dfc88ceae56e4e9724a42ac0db492c0e707a4
The in_cdb.length (ALLOCATION_LENGTH) must be set in order to send
SECURITY PROTOCOL IN command.
Bug: 143636526
Test: Trusty storage tests
Change-Id: Ie4252e9b19c05825c895ec07f8c9684ae456f6c9
The newer way of specifying the interface is using <fqname> and it also
has the handy side-effect of not causing conflicts when we add the
strongbox implementation to devices.
Test: make # check $OUT for the correct manifest
Change-Id: If8333814723261c4f3de375861ee19a6d922d55f
Library based HALs have been deprecated for several years now, and
Keymaster 2 based testing is woefully out of date compared to running
VTS against the modern 3.0 and 4.0 implementations.
Purging these modules and their resulting dependencies will make it
easier for the central system/keymaster repository to move forwards.
Test: mm
Bug: 150239636
Change-Id: Ic2ddbe685a50e65f9db25f682ad33105195efa8a
This implementation does not provide any security guaranties.
* The input method (NotSoSecureInput) runs a crypto protocols that is
sufficiently secure IFF the end point is implemented on a trustworthy
secure input device. But since the endpoint is currently in the HAL
service itself this implementation is not secure.
* This implementation provides most of the functionality, but not the
secure UI infrastructure required to run Android Protected
Confirmation.
Bug: 146078942
Test: VtsHalConfirmationUIV1_0TargetTest
Change-Id: I14717b5fa4ef15db960cdd506b8c6fe5369aec8d
The UFS support got rebased on top of the RPMB socket support
improperly. As a result, RPMB socket support was broken due to an
unconditional rmpb_fd = rc which would set the rpmb_fd to be connect()'s
error code in the case of an RPMB socket.
Bug: 146903427
Test: Boot Trusty+Android with the rpmb_dev mock, check for liveness
Change-Id: Ib1220dc49392f1a10369eed7716e44680bd83a66
This CL enables storageproxyd to run on UFS device.
The proxy prepares and sends SECURITY PROTOCOL IN/OUT commands to UFS
device.
Bug: 143636526
Test: Trusty storage tests
Change-Id: Ibe16578c12b978c9a95deccfb1873081e8d0e994
When developing, it may be preferable to operate on a device which does
not have a real RPMB storage, or which is unprovisioned. This CL allows
the rpmb_dev program to act as a daemon serving a fixed key, and for
storageproxyd to speak to rpmb_dev's socket rather than an actual rpmb
device or a virtual rpmb device.
Test: Trusty Gatekeeper VTS
Change-Id: I19b2b143fffb8e68e4a028d00eaf5cd1928e12f6
This makes it easier to add or remove the Trusty keymaster service from
a device by providing a manifest fragment to add whenever it is enabled.
Test: Keymaster VTS, Keystore CTS (sans attestation)
Change-Id: Ib0f5fd7c016c0c18d77c9d2623c89f3b35ba7ad7
The reference keymaster at system/keymaster still expects to receive its
auth tokens in the tags, rather than as a separate parameter. This
change injects the separate parameter passed to the KM4 HAL as a legacy
tag in the request.
Longer term, system/keymaster should support a separate authToken
parameter, and it should be serialized and sent to Trusty separately.
Test: Keymaster VTS + Keystore CTS (sans attestation)
Change-Id: Ie69cbd358504bb7612f7d55158509043cdad4e4e
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I0bdffced6af52695c0ef98c9dd659348e56f7aa6
This patch replaces the legacy libhardware based gatekeeper HAL with a
true HIDL based implementation.
Test: Workes with trusty gatekeeper
Change-Id: I072b0c3fc74523400132aacd34e2f2cac9cf261b
Merged-In: I072b0c3fc74523400132aacd34e2f2cac9cf261b
Adds support for proxying V4.0 commands to Trusty and makes 4.0 the
default when including trusty-base.mk.
Bug: 128851722
Test: Keymaster VTS 4.0 + Trusty
Change-Id: I2e2220963996fcb88d6953ee1a58af1b947b857d
Previously we only installed the gatekeeper.trusty.so library, which is
insufficient to actually start Gatekeeper. We now also install the -impl
and -service wrappers.
Bug: 127700127
Test: Gatekeeper 1.0 VTS with Trusty running
Change-Id: Idd8d6a4e1e409c2a712dddfd92d5f9cf6b16b50c
In order to test Trusty gatekeeper automatically, the storage proxy
needs to be active inside the emulator. This patch allows storageproxyd
to speak a length-framed RPMB to an external RPMB daemon.
For a concrete example of a daemon speaking this protocol, see rpmb_dev
in the Trusty tree.
Bug: 124277696
Test: Launch storageproxyd with -t virt, use Trusty test infra
Change-Id: I391d4768976f0eb1f3b8df58eefd58fc3a9409cd
These files were previously not clang-format clean. I am submitting the
clang-format cleanup in its own CL to avoid mixing up the code I'm
adding/adjusting with old code which needed to be reformatted.
Bug: 124277696
Test: m
Change-Id: I8a57ca97925a16bee10b15d2013a5dcf87b0ed15
It is designed to connect to user specified port and
implements unittest logging protocol supported by
typical unittest ap running on Trusty side.
Test: manual
Change-Id: I6e37ccee9b9e4dde563ef0e4f531b42091cc2bd8
Modify TrustyKeymaster3Device::update method to handle the case when
amount of input data received exceeds a maximum amount supported by
underlying transport. In such case, only send an portion of data that
fits and allow higher levels to take care of the rest.
This is not an ideal fix as it is not very efficient for large sets
of data but at least it should work in more cases.
Test: android.keystore.cts
Change-Id: Id7360d0da3b87493193d480fc0c78c65dc1fc51f
KM1/KM2 implementations should treat nullptr and KeymasterBlob{nullptr, 0}
equally when passed in as client_id or app_data. However, trusty KM1
treats them differently.
Bug: 113110105
Bug: 113084196
Change-Id: Ie0e2b5d60d808e4f7a8e48aeb4c694268f9bc0a1
the new layer (Keymaster2PassthroughContext) will call the related function
operation, however, currently it’s null so it will have null pointer reference
issue and we need to provide them in the keymater legacy HAL.
Bug: 113084196
Change-Id: Id1b0df47c03d341aedc7a0634cb101966143641c
This message was originally ALOGV but got accidentally changed during a
refactoring in 81ebcb1943
Bug:110153632
Test: VtsHalKeymasterV3_0TargetTest
Change-Id: Ibdfa0ab50cb8544c6f23c15049904f1741769647
This allows the IPC functionality to be used by multiple HAL
implementations
Test: trusty_keymaster_tipc & keystore.trusty compile
Bug: 110153632
Change-Id: I78f273db6f59a417319058113e15e422ece73290
Added three new directories:
- include: contains ipc and legacy header files
- ipc: contains common keymaster IPC code that can be shared between HALS
- legacy: contains the old style HAL implementation
Test: trusty_keymaster_tipc & keystore.trusty compile
Bug:110153632
Change-Id: I2fdaa9d3d0421a0e359c05807ab5f0a12c5d3996
