(This is a merge of http://go/wvgerrit/152969.)
C++ makes absolutely no guarantees about the order of initialization of
global variables in different compilation units. The class-scope static
WvCdmTestBase::default_config_ in test_base.cpp invokes the
ConfigTestEnv constructor on creation, which depends on the prior
initialization of several file-scope static variables in
config_test_env.cpp. Since those are different compilation units, there
is no guarantee that they will initialize in the correct order to avoid
referencing uninitialized memory. This is one of the reasons Google
Style really encourages people not to have global-scope variables with
complex types.
As it happens, on all our internal platforms, these files get linked in
such a way that the variables get initialized in the right order and
there is no crash. But that's not guaranteed, and some partners have
reported crashes here. In at least one case, the "right" linker order
was platform-dependent, and the partner ended up having to maintain
separate linker orders for separate platforms.
This patch defers default_config_ initialization until
WvCdmTestBase::Initialize() is called. By that time, all static
variables will be initialized, so it will be safe to reference them.
Bug: 173252165
Test: x86-64
Test: build_and_run_all_unit_tests.sh
Change-Id: If31128a999c7d6945f47293ca57f08e43d8274de
[ Merge of http://go/wvgerrit/153489 ]
OEMCrypto does not provide an API for retrieving the system ID when
the TEE uses a built-in DRM certificate (provisioning 1.0). New OEMs
and Android devices do not use prov 1.0; however, the Zimperium CDM
(at least the tests) use a built-in certificate and are failing
certain tests because of the missing system ID. To address this
failure; the CDM SystemIdExtractor has been updated to return a null
system ID.
Bug: 235879962
Test: system_id_extractor_unittest
Change-Id: Ib4c2bd75a7825967b0aa9e31e144184ae18fe8fb
In CreateCoreLicenseResponse(), there seems to be an out of bounds
potential error due to a missing check that the index used for
license_response.parsed_license->key_array is valid. Adding a check
for this here.
Bug: 217677571
Test: fuzz tests
Change-Id: I37f7228f87992ba5284c553d7b07ef97d6a66ab3
[ Merged from http://go/wvgerrit/152493 ]
Replace struct with class for WVDrmFactory, WVCryptoPlugin
and WVDrmPlugin.
Also fix build_all_unit_tests.sh, hidl_metrics_adapter_unittest
has been renamed to hal_metrics_adapter_unittest.
Test: unit tests
Test: Google TV and Netflix
Test: atest GtsMediaTestCases
Bug: 216717460
Change-Id: I92b15510267e8f37058845be760a6ec6241bc5d7
[ Merge of http://go/wvgerrit/152674 ]
This allows an app to query the provisioning model. Possible
values are { "DrmCertificate", "Keybox", "OEMCertificate",
"BootCertificateChain" }
An app can use these to disntinguish between provisioning models.
Provisioning 4.0 (boot certificate chain) requires a double provisioning
step.
Bug: 234057551
Test: WV unit/integration tests, libwvdrmdrmplugin_hal_test
Change-Id: I1611488ec632a0e5a9e1d106b7475e8f5a2a5a13
This is a merge from:
https://widevine-internal-review.googlesource.com/c/cdm/+/152372
The L3 source change which produced these libraries is:
https://widevine-internal-review.googlesource.com/c/cdm/+/152371/
Original commit message:
To address the bug with certain 16.4.x SDK versions returning a
clear key control block (KCB) for clients newer than 16.5, the
exact version check to determine whether key control blocks are
clear or not has been loosened.
Original behavior:
- ODK version >= 16.5.x --> Assume clear
- ODK version <= 16.4.x --> Assume encrypted
New behavior:
- No KCB IV --> Assume clear
- Otherwise --> Assume encrypted
This CL also includes a change to oemcrypto/include/OEMCryptoCENC.h
The changes to OEMCryptoCENC.h in the CL are comments or variable name
change. So it should be safe.
This change was merged to wv tm-dev here:
https://widevine-internal-review.googlesource.com/c/cdm/+/148411
So, adding it to Android tm-dev.
Test: run_level3_static_tests, CdmDecryptTest/CdmTestWithDecryptParam.* against LS SDK 16.4.2 & 17.0
Bug: 232557453
Change-Id: I2bbb5ab3ea33a16bd6c198077e5aefe960737ea0
(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
(This is a merge of http://go/wvgerrit/151891.)
A previous patch changed how we skip padding when extracting keys from
key containers in license.cpp. Unfortunately, this broke generic
signing when an ODK core message is not in use:
1) "Content" keys for signing are 32 bytes long, but content keys were
assumed to be 16 bytes long.
2) When an ODK core message IS in use, the result of the extraction in
license.cpp is ignored.
The only way to know the correct length of a content key container in
License Protocol 2.1 is to leverage the knowledge that it will always be
padded by exactly 16 bytes. This will have to change if we ever
implement support for License Protocol 2.2, as all key containers are
unpadded in that version.
Bug: 231439638
Bug: 114159862
Test: oemcrypto_dynamic_v15
Change-Id: I1d6c24b3a922247b970fd1517c6f23aded570adf
