This is based on a patch submitted by Amlogic.
When we're doing decrypt fallback, either in the CDM or the OEMCrypto
tests, we sometimes fall back to a point where we're synthesizing new
samples and/or subsamples for the content being decrypted. When this
happens and the output buffer is clear, we should limit the size of the
output buffer to only the space needed to hold the output.
Previously, we've been passing the entire output buffer to every call.
This can create a problem if the reason for the fallback is a lack of
enough memory to communicate the buffers to the TA, since the output
buffer will remain the same size as the total output. Restricting the
buffer passed to each call to only the space needed by that call will
reduce the memory requirement.
Bug: 354834629
Test: x86-64
Merged from https://widevine-internal-review.googlesource.com/204810
Merged from https://widevine-internal-review.googlesource.com/204953
Change-Id: I412f43d8f88c72072ef1dd5293436bdb58e500b3
[ Merge of http://go/wvgerrit/194374 ]
Renames and adds clarifying comments to Drm Reprovisioning token types.
All provisioning methods can be forced to reprovision by apps which can
cause reprovisioning to be an overloaded term. Renaming token types
used by the Drm Reprovisioning method to more clearly state they are
used for Drm Certificate Reprovisioning should help to avoid confusion.
This change also adds comments to help clarify when and where Drm
Reprovisioning is used as a provisioning type.
Bug: b/305093063
Test: WVTS
* Added dependency to dynamic perf tests to fix missing header build
error.
Change-Id: I158eb5672ad9e655a60bc68e0f4f2f7a0d464b4e
[ Merge of http://go/wvgerrit/192010 ]
Updates the CDM to add support for DRM reprovisioning request creation.
- Load the baked-in certificate for use as the client token.
- Add functions to build and sign a drm reprovisioning request.
- Update the Rikers L3 OEMCrypto implementation to support signing
provisioning requests and getting embedded certificate.
- Update client id token to handle DRM reprovisioning.
- Add OEMCrypto function to load the baked-in device certificate in
Rikers CDMs and stubs for non-Rikers CDMs.
- Add dynamic adapter support for getting embedded device certificate
only on L3.
Bug: 305093063
Test: WVTS
Change-Id: I9a0ecf95e27213b046f03baa0781fb164179323b
BCC supports two types of format: CBOR and X509. The latter will be
used by Chrome OS. In case of Prov4, BCC type will be queried by
OEMCrypto_GetBCCType() and the returned value is populated in the
provisioning request.
This CL adds X509 type to protobuf, a call from CDM to query BCC type
and OEMCrypto adapter changes for this call.
Test: run_fake_l1_tests, opk_ta_p40
Bug: 307969500
Change-Id: I88acc36da6cb413d537a9ea9dfd2a150d4557595
Since KDF functions are only used right before specific functions, this
merges them to simplify internal state within OEMCrypto.
Fixes: 299527712
Change-Id: I426cfcdc102bd73cf65cd809b213da2474f44b34
The current implementation of OEMCrypto_SetDecryptHash gives developers
flexibility to use different types of hashes. However, all the
implementations we have seen thus far use crc32. Because of this, crc32
should be sufficient and we can refactor OEMCrypto_SetDecryptHash to
only use the crc32 hash.
Bug: 287706586
Change-Id: I4aaa253b2656dfd9c984f77dfb08fe160b23b47c
Creates parameterized certificate provisioning tests to prepare for DRM
reprovisioning implementation.
- Create parameterized certificate provisioning test suite.
- Change RETURN_IF_NOT_OPEN macro to call IsOpen instead of checking
the |open_| variable to make mocking of CryptoSession methods easier.
Bug: b/305093063
Merged from https://widevine-internal-review.googlesource.com/188051
Change-Id: Ic1c344af64073a8ff5626530a0864bfeea90fc6e
GetDeviceInformation() and GetDeviceSignedCsrPayload() are added to
cdm_engine and crypto_session, so that they can be queried by DRM
plugin. This is to allow the wv drm HAL to be able to extract BCC and
CSR payload to build CSR for prov 4 device registration, such that we
don't need a separate RKP HAL to do this job.
Changes to the DRM plugin to use the exposed methods will be in the
coming CL.
Bug: 286556950
Test: request_license_test
Merged from https://widevine-internal-review.googlesource.com/178890
Merged from https://widevine-internal-review.googlesource.com/179730
Change-Id: Ibafa3a58c99fbb8f1f25f8951d3749110bd32176
[ Merged of go/wvgerrit/186370 ]
CDM by default allows test keybox from device side.
Bug: 299987160
Bug: 301669353
Change-Id: I06f1936ccd068eb71364a5a8931970954233b686
[ Merge of http://go/wvgerrit/181152 ]
[ Cherry-pick of http://ag/24137228 ]
Partners have requested that we log HDCP information during certain
operation:
1) Current and max HDCP capability when calls to decrypt or select
key failure due to insufficient or mixed HDCP levels.
2) Current, desired and default HDCP level when video contraints
are not met.
To avoid spamming the logs, decrypt failures are only logged on their
first occurrence, and unmet video constrains when one of the
requirements change.
Bug: 276686656
Bug: 292005982
Test: license_keys_unittest
Test: Android WVTS on oriole
Change-Id: I98b18e66d7ce1c474a018ae83af4f1c0b03308df
(cherry picked from commit c84b9afd38)
[ Merge of http://go/wvgerrit/169450 ]
OEMCrypto v17 introduced several new HDCP levels that OEMCrypto may
report; however, the CDM never updated to support them. The enum
values of the additional levels are no longer sequential with their
level of support (v1.1 is 7, and v2.1 is 3), this requires more
considerations when comparing the required HDCP levels (as specified
by the license) and current HDCP level supported by OEMCrypto.
The following rules were used:
1) HDCP_NONE is the absolute lowest level
2) HDCP_NO_DIGITAL_OUTPUT is the absolute highest level
3) HDCP_V1 is treated as equal to all V1.x levels
4) All other versions are based on their major-minor pairs
Bug: 269671291
Test: license_unittest
Test: policy_engine_constraints_unittest
Test: policy_engine_unittest
Test: GtsMediaTestCases
Change-Id: Ibecfcb981d7e019c68cb8e0c7286222253d18369
[ Merge of http://go/wvgerrit/168482 ]
The function OEMCrypto_GetBootCertificateChain() does not always
provide an additional signature depending on the device. However, the
CDM would still attempt to dereference the first character in the
additional signature buffer when empty. This CL changes how the data
pointer to an output string is acquired. Empty string will instead
pass in a null pointer.
Bug: 272643393
Test: run_prov40_tests
Test: atest GtsMediaTestCases
Change-Id: I10b0a3c7df4fc73272aa701bb01c60672645d4fc
(cherry picked from commit a878e7b98d)
(Merged from http://go/wvgerrit/165859.)
Since renewal requests are signed with the MAC keys and not an
asymmetric key, it does not make sense to query OEMCrypto for the
asymmetric key hash algorithm nor to include the result in the renewal
request.
Bug: 262427121
Test: opk_ta
Change-Id: Ib309b63b79e553f4754c013718df242247ab9488
[ Merge of go/wvgerrit/c/cdm/+/165138 ]
Enabled the Widevine DRM service on Android to return the raw boot
certificate chain via the CDM status query capabilities. This
property key is not available for app-level queries.
The BCC is dumped by the WVDrmFactory when requested to print all
CDM properties via dumpsys.
Bug: 234095402
Test: request_license_test
Test: adb shell dumpsys android.hardware.drm.IDrmFactory/widevine -p
Change-Id: I34695b0655b4c609979577e9986974bc0fbda898
[ Merge of http://go/wvgerrit/164077 ]
This CL makes major changes to the names of variables and types that
are related to the usage table, header, entries, entry indexes, and
other related data.
The renaming followed these rules:
1) "Usage table header" will exclusively refer to the header blob
that is OEMCrypto specific. The CDM class "UsageTableHeader"
is the CDM-layer's abstraction around the "usage table" concept.
The name has been updated to reflect that.
2) The "Cdm" prefix is only used for the CDM-specific data types for
the usage table and entry info. It has been removed from
OEMCrypto-specific types.
- UsageTableHeader -> CdmUsageTable
- CdmUsageTableHeader -> UsageTableHeader
- CdmUsageEntry -> UsageEntry
3) The "usage_" prefix has been removed from variables when the usage
table or usage entries are the subject of the function or class.
4) UsageEntryIndex is the type for entry indexes, instead of directly
using uint32_t. This matches how we wrap other types in
"wv_cdm_types.h"
5) Changed entry "number" to entry "index".
6) Vectors of elements have been renamed to be either pluralized or
have a suffix "_list".
7) "Usage info" was occasionally being used to refer to the usage
table or entries generally, rather than specifically secure-stop.
- CryptoSession::HasUsageInfoSupport() -> HasUsageTableSupport()
The most major change is that the files "usage_table_header*" have
been renamed to be "cdm_usage_table*".
Bug: 242914226
Test: run_x86_64_tests and request_license_test
Change-Id: Iee98446b71f4f2934d3c9e0fb949eb05b84d1f8c
No-Typo-Check: From a third party header file
Bug: 260918793
Test: unit tests
Test: atp v2/widevine-eng/drm_compliance
Change-Id: I36effd6a10a99bdb2399ab1f4a0fad026d607c70
1. "Change CdmResponseType from enum into a struct"
Merged from http://go/wvgerrit/163199
Bug: 253271674
2. "Log request information when server returns 401"
Bug: 260760387
Bug: 186031735
Merged from http://go/wvgerrit/162798
3. "Specify server version on the command line"
Bug: 251599048
Merged from http://go/wvgerrit/158897
Test: build android.hardware.drm-service.widevine
Test: Netflix and Play Movies & TV
Test: build_and_run_all_unit_tests.sh
Bug: 253271674
Change-Id: I70c950acce070609ee0343920ec68e66b058bc23
[ Merge of http://go/wvgerrit/160000 ]
OEMCrypto v15 licenses made use of several now-obsolete API functions
of OEMCrypto (mainly LoadKeys and RefreshKeys). All license handled
by the CDM must be v16 or newer. The CDM can now rely on all license
requests/responses containing a core message, using v16 policy timers,
and requires loading using LoadLicense() / LoadRenewal().
Bug: 252670759
Test: run_x86_64_tests and policy_engine_unittest
Change-Id: I3f65a6ec0326b4c89d1919b8911e065079cb90d2
(This is a merge of http://go/wvgerrit/151930.)
While grepping the code to respond to some CR feedback, I noticed a few
places where we had sprinkled some unnecessary "const" specifiers
amongst constexpr declarations. This patch cleans them up. There should
be little semantic difference in the code after this patch, as it only
removes specifiers that were redundant. The only exception is where
"constexpr const char* X" was converted to "constexpr char X[]", which
has slightly different semantics in edge cases we don't use.
Test: x86-64
Bug: 231439638
Change-Id: I0b33777f8d3b718a3410f6d802c51b1220508d34
[ Merge of http://go/wvgerrit/151391 ]
This CL moves the logic for extracting the system ID from keybox or
OEM certificate (from OEMCrypto or device files) to a dedicated
SystemIdExtractor.
Before Provisioning 4.0, the system ID could only be found from data
returned by OEMCrypto. However, with provisioning 4.0, the system ID
can now be found in the OEM certificate that is stored on the device
files.
Bug: 232020319
Test: system_id_extractor_unittest
Test: Forest L37800000954493485
Change-Id: Ie1b7987906e2e4fef015cd659a947b6dbb7594b1
[ Merge of http://go/wvgerrit/151749 ]
Extended CryptoSession for recording the result of
OEMCrypto_ProductionReady().
Only OEMCrypto_SUCCESS is considered "production ready". With the
exception of OEMCrypto_ERROR_NOT_IMPLEMENTED, any other result is
vendor-specific and indicates not being production ready.
Bug: 231655151
Test: metrics_collections_unittest
Change-Id: Ia0e5603d7ee1290238cce63d0194ae1aced424c1
[ Merge of http://go/wvgerrit/151518 ]
Extended the CDM layer to report OEMCrypto's production readiness
via string property query.
If OEMCrypto implementents OEMCrypto_ProductionReady(), then the
reported readiness by the CDM will report "True" or "False".
If OEMCrypto does not implement OEMCrypto_ProductionReady() then no
level of readiness is assumed, and the CDM will report "Unknown".
Bug: 231655151
Test: run_prov30_tests and request_license_test
Change-Id: I6afe481ef00ac129d02b004eca89a65810bfbff8
[ Merge of http://go/wvgerrit/151191 ]
Within the CDM and OEMCrypto tests, there were a few OEMCrypto function
calls where the final size of the output buffers were not being
resized. For several of these functions, an initial call is made with
zero-length output buffers, expecting OEMCrypto to return
ERROR_SHORT_BUFFER; followed by a call with buffers at least as large
as specified by OEMCrypto. However, for some operations, OEMCrypto
makes an estimate on the final size on the first call, specifying the
exact size only after performing the operations.
This is the case for the wrapped key returned by
OEMCrypto_LoadProvisioning(). The provisioning response contains a
padded + encrypted DRM key. OEMCrypto does not know the actual size
of the key until decrypted, and the actual DRM key might be smaller.
There was a OEMCrypto test for OEMCrypto_BuildInformation() which
was enforcing the wrong behaviour. This has been updated.
Bug: 230661565
Test: oemcrypto_test
Change-Id: Iad297d56ffbb085894641fdf8698ce5fd18edbf2
[ Merge of http://go/wvgerrit/149690 ]
This changes extends the CryptoSession logging to include the OEMCrypto
session ID in its decrypt failure logs, and adds a new CdmSession
decrypt failure log which includes the CDM session ID. The CDM session
directly maps to the MediaDRM session ID, making app debugging easier.
The Decrypt() code pathway is one of the most frequently called
portions of the CDM code, and the pathway attempts to make as few
logging calls as possible in order to keep latency low and log
verbosity to a minimum. It is anticiapted that when a call to
Decrypt() fails, there will be a burst of failures as the app may
make several calls to Decrypt() before handling the first decrypt
error.
To keep logging low, the following rules are followed:
- CryptoSession: decrypt errors are only logged when the decrypt error
changes.
- CdmSession: decrypt errors are only logged when the last call to
decrypt had succeeded.
Bug: 183984396
Test: MediaGTS with decrypt failures
Change-Id: Ic6124646d129efbc8a690b5bfd4dc422e04e677b
[ Merge of http://go/wvgerrit/148552 ]
Extended the CDM layer to report OEMCrypto's watermarking support.
The reporting of watermarking comes in three (3) mechanisms:
1) ClientCapabilities in license requests
2) CryptoSession metrics when queried to OEMCrypto
3) String property query by apps
If OEMCrypto implementents OEMCrypto_GetWatermarkingSupport(), then
the reported watermarking support by the CDM will match that of
OEMCrypto.
If OEMCrypto does not implement OEMCrypto_GetWatermarkingSupport()
or an error occurs, it is assumed that OEMCrypto does not support
watermarking, and the CDM will report "Not Supported".
Bug: 226443788
Test: run_x86_64_tests request_license_test and license_unittest
Change-Id: Id929a356c395e6bcf45d371ee6887eec40d35329
[ Merge of http://go/wvgerrit/149130 ]
When re-initializing OEMCrypto for testing purposes, the
UsageTableHeader must be reset as well. This is to inform future
sessions to load or create a new header before creating new entries.
Bug: 219075437
Test: request_license_test and MediaDrmTests GTS
Change-Id: Ie8bc72bc7ea079d21587e114223fcb67547c756a
[ Merge of http://go/wvgerrit/148469 ]
OEMCrypto_GetOEMPublicCertificate needed to be called
before the OEM private key was loaded due to a bug in OEMCrypto.
The bug has been addressed and the call can now be removed.
OEMCrypto_GetOEMPublicCertificate is only applicable to
devices with OEM certs as their root of trust. Devices with
keyboxes (or BCC) as their RoT would return a spurious
error OEMCrypto_ERROR_NOT_IMPLEMENTED. Removing the call
addresses this as well.
Bug: 190231658
Test: WV unit/integration test
Change-Id: I8216ca5a78b8c2acb5681c7f599cdc41efdf9fc7
The interface is defined in
hardware/interfaces/drm/aidl(http://go/ag/15329852).
Test: build
m android.hardware.drm-service.widevine -j128
Test: build_and_run_all_unit_tests.sh
for hidl tests
Test: atest VtsAidlHalDrmTargetTest
Bug: 200055138
Bug: 170964303
Change-Id: If2f2a129914436ba5cef1c46f6cb9415e12c3d1c
[ Merge of http://go/wvgerrit/143370 ]
[ Cherry-pick off http://ag/16624952 ]
Devices without a keybox may not have access to a device ID if the OEM
uses the device ID from the keybox as its source of truth. For
devices which have lost their keybox, OEMCrypto_GetDeviceID() was
assumed to return ERROR_KEYBOX_INVALID if that was the case; however,
Qualcomm's implementation was returning ERROR_NO_DEVICEID. Given that
both error codes are appropriate, the CDM has been updated to accept
both as an indication that the device ID cannot be retrieved, and that
the null device ID should be returned.
Bug: 190504842
Bug: 214113125
Test: Manual test
Change-Id: I8fb8a1bddfe895062b707b51fcadffd983adb40e
