[ Merge of http://go/wvgerrit/152650 ]
There are two LOGEs in device_files.cpp that would frequently trigger
during testing despite the condition they were logging being totally
normal. The files were not present because the device had never had to
write them yet. This patch downgrades these bengin errors to warnings
to reduce log spam.
Test: build_and_run_all_unit_tests.sh
Bug: 236317198
Change-Id: I56f9d477f8a6b26635f0eb4a6b7c636e866381d3
[ Merge of http://go/wvgerrit/148729 ]
A recent merge from google3 of the ODK code broke builds on the
oemcrypto-v17 branch because it depended on a license_protocol.proto
change that had not been brought over yet. This patch brings over the
missing line to fix the build.
Test: build_and_run_all_unit_tests.sh
Bug: 236317198
Change-Id: Ia8133696f3156c16ef4bd1382358be5da6159820
(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
(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
[ 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/151512 ]
Parameterizing GtsMediaDrm tests exposed a few issues. If secure stops
were stored at L3 security level, retrieval would fail. This CL
checks L3 if the secure stop was not found at the default security
level.
Bug: 221249079
Test: GtsMediaTestCases
Change-Id: Ie88197f8e29457981d782199a76d38774f6faa67
[ 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
Merged from https://widevine-internal-review.googlesource.com/148554
This change was merged to master but missed in tm-dev when we stopped
the auto merging to tm-dev. Manually cherry picked it.
Test: ran OPK unit tests
Bug: 230820162
Bug: 180530495
Change-Id: Ib23f07f84096650beb4dd1950105db01e004d484
(This is a merge of http://go/wvgerrit/151112.)
The Widevine CDMs have never validated the padding on AES keys. However,
the code to ignore the padding was unusual and based on the assumption
the keys would always have either 0 or 16 bytes of padding and did not
handle other cases correctly. This patch updates the padding-ignoring
code to just do the obvious thing: Reject keys that are too small and
ignore all extra bytes regardless of count.
Bug: 114159862
Test: x86-64
Change-Id: Ic48010477e4cb5f7d2afbde25cf2f098e3470089
[ 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
(This is a merge of http://go/wvgerrit/150131 to the Android repo.)
This patch changes the code path in the CDM so that the first-stage
provisioning request for Provisioning 4.0 is always encrypted with the
Widevine service certificate instead of the client-set service
certificate, reflecting that the first-stage provisioning is always
handled by Widevine.
This patch also makes several methods on the ServiceCertificate class
const. This has no impact on their behavior.
Bug: 221443151
Test: prov40 tests
Change-Id: Ide4c3927afadcd45ae7fb629b99e2f55cc29d56e
[ Merge of http://go/wvgerrit/150630 ]
DeviceFiles uses a static variable for tracking license IDs which
have been reserved by a CDM session before officially storing the
license on the device. This variable was not protected by a mutex,
and a rare race condition would arise, either crashing the service
or getting it stuck in a loop.
This CL adds a mutex for protecting the set of reserved IDs.
Bug: 226555704
Test: device_files_unittest
Change-Id: Icdea88673c76c267b4b7db79697ec52ae8e2581e
[ 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
[ Merge of http://go/wvgerrit/148450 ]
This CL adds threading requirements to the method doc-comments of
UsageTableHeader.
Bug: 189366337
Test: usage_table_header_unittest
Change-Id: I671f702d3e8ec219cc8daaa220133cb8cec183c8
[ Merged from http://go/wvgerrit/143750 ]
The old test license holder would generate a minimal license response,
but could not correctly mimic important server logic introduced in the
v16 server. Since all integration tests now have policies on the UAT
server, we do not need these minimalist license responses anymore.
Bug: 192700112
Test: GtsMediaTestCases on sunfish
Change-Id: I78c1b6085a6d0239840a11f2b904902210e5e61c
[ Merged from http://go/wvgerrit/143635 ]
Use a license holder for the generic crypto tests.
Bug: 192700112
Test: GtsMediaTestCases on sunfish
Change-Id: Ia2c802263562b11845e55ae0a24254ea54e364c7
[ Merge of http://go/wvgerrit/143749 ]
Tests are added to verify that the policy durations are enforced for
an offline license after a device has been rebooted.
Bug: 26163469
Test: GtsMediaTestCases on sunfish
Change-Id: I54e65d7abc5e59eae7c150555b2244dbf96da3f5
[ Merge of http://go/wvgerrit/143634 ]
Refactor the policy integration tests to use the license holder.
Bug: 195691232
Test: GtsMediaTestCases on sunfish
Change-Id: I58ffa64caec05c617065e4781657e85914f8369e
Merged from http://go/wvgerrit/146154
Many integration tests require a license from a license server. This
CL creates a helper class to fetch, load, and hold a license.
Test: ./build_and_run_all_unit_tests.sh
Bug: 194342800
Bug: 194342778
Change-Id: I0de7bcab4db1b365f074bad29fc157a5eca135d8
[ Merge of http://go/wvgerrit/143630 ]
When we run a test with the fake clock, the clock had been initialized
to the current time, or to 0. This causes a problem for reboot tests
because the clock might go backwards over the reboot. With this
change, we monitor the clock at the end of one reboot pass and
initialize the clock for the next pass based on the previous value.
Bug: 26163469
Test: GtsMediaTestCases on sunfish
Change-Id: Ibd0024f963634382af70553fced38da6e1d857d2
[ Merge of http://go/wvgerrit/143629 ]
The standard b2a_hex only saves about 2k, so we need a special version
that can handle larger strings. This is needed because a license file
is about 7k.
Bug: 194342751
Test: GtsMediaTestCases on sunfish
Change-Id: I6a6ac3f8f4fa6d9cd8a0119fc64fc8f3cc5f3ae8
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
