(This is a cherry-pick of http://go/wvgerrit/104184.)
UBSan has detected several places where our code tripped over what is
technically Undefined Behavior when handling enums, although in practice
any compiler would still generate safe code.
Some of these were places a variable was not being initialized and thus
was filled with garbage data. These have been fixed.
Understanding the rest depends on a bit of C++ trivia I had certainly
never heard before: An enum that doesn't specify its backing type will
frequently have a gap between the range of values the compiler will let
it take (which is limited only by the size of the backing type assigned
by the C++ standard) and the range of values for which the C++ standard
defines the behavior. (which is limited by the minimum number of bits
needed to hold the largest valid enumeration entry) So, for example, an
enum containing ten entries numbered 0 through 9 would be stored in
memory as an int and could thus take any value in the range of an int.
But it only takes 4 bits to represent the numbers 0 through 9. The
largest number that can be represented in 4 bits is 15. So reading the
value of a variable of this enum type when its stored value is outside
the range 0 to 15 is undefined behavior.
An enum that specifies its backing type is not subject to this because
it is defined behavior to access any value representable in the backing
type if one was explicitly specified.
If you think this sounds a bit silly, you'll be happy to know it doesn't
apply from C++17 onwards and most compilers generate code that handles
the undefined behavior values correctly.
Nonetheless, to appease UBSan and protect us from any compilers that
actually rely on this undefined behavior for optimizations, I have
defined backing types for all our enums. I have defaulted to the type
the compiler was already using (int32) and have deviated only where an
enum exists to be compared to or filled from a protobuf field and that
field in the protobuf is unsigned, in which case I used a uint32.
In the case of the CE CDM exported API, this also required changing our
enums from C-style to C++-style.
Bug: 163080356
Test: CE CDM Build & Unit Tests Pass even with UBSan
Test: Android Build & Tests
Change-Id: Id7e0064129e7c4d2827bb4a94825d144eeaacec8
[ Merge of http://go/wvgerrit/103243 ]
Include review comments from wv gerrit CL.
Bug: 161551490
Test: WV unit integration tests, GtsMediaTestCases and
WidevineConcurrentDrmCertificatesTest#testConcurrentDrmCertificates,
MediaDrmTest#testMultipleLoadKeys on a redfin
Change-Id: Ie9b41a2e68b95692f9353578f6955637411d4dfc
[ Merge of http://go/wvgerrit/103395 ]
To help with debugging failures in HTTP requests during unit tests,
this CL adds logging for Google's debugging response header fields.
These fields are of the type "X-Google-*" or "x-google-*" and provide
information such as the service name, server cell, error details, and
other details that can help isolate the cause of failure on the
server's end.
An additional unittest has been created to test the parser for the
header fields.
Tests that are known to exprience HTTP failures have been extended
to include logs for these fields should they be present.
Bug: 137619348
Test: Linux unit tests and Jenkins test
Change-Id: I69959af2ba91510f345bbb02cf7ca35c3f1119da
[ Merge of http://go/wvgerrit/103684 ]
[ Cherry pick of http://ag/12221244 ]
The OEMCrypto method for usage table capacity can return zero to
indicate that the usage table size is not explicitly limited. The
CDM must handle this case with regard to the CDM's usage table
management and information querying.
The usage table initialization tests are extended to include cases
where the table does not have a defined limit.
AddEntry() was missing call to update the usage table header after
creating a new usage entry. This call is now included and required
additional changes to the usage table unit tests.
Bug: 160560364
Test: Android unit tests
Change-Id: Ica5d181092d2938d24deba5005a211ca883cb0f0
[ Merge of http://go/wvgerrit/102945 ]
The OEMCrypto method for usage table capacity can return zero to
indicate that the usage table size is not explicitly limited. The
CDM must handle this case with regard to the CDM's usage table
management and information querying.
The usage table initialization tests are extended to include cases
where the table does not have a defined limit.
AddEntry() was missing call to update the usage table header after
creating a new usage entry. This call is now included and required
additional changes to the usage table unit tests.
Bug: 160560364
Test: Android unit tests
Change-Id: Ica5d181092d2938d24deba5005a211ca883cb0f0
[ Merge of http://go/wvgerrit/103243 ]
In v16, OEMCrypto specifications required that an error be returned if
multiple attempts are made to load an offline license into a session.
This caused the GTS test testConcurrentDrmCertificates to fail. It was
introduced to verify that a license could retrieved and loaded into a
session and then restored. This was based on an app use case.
Ideally we would like to disallow a this behavior but need to make sure
it is not being used by apps.
For now this will be allowed. If detected, the CDM will reintialize the
OEMCrypto session and allow the license to be restored.
Bug: 161551490
Test: WV unit integration tests, GtsMediaTestCases and
WidevineConcurrentDrmCertificatesTest#testConcurrentDrmCertificates,
MediaDrmTest#testMultipleLoadKeys on a redfin
Change-Id: I0834e4419c3a6dccfd77aaea3afa3d65c2c0c742
[ Merge of http://go/wvgerrit/102923 ]
Avoid logging an error, on first boot, when trying to retrieve a
certificate that does not yet exist.
Bug: 161201883
Test: WV unit/integration tests
Change-Id: I293f9766a7f2024107d0db45a874a9478b0c3959
Base class uses license_start_time_ which is not updated on renewals.
Merge of http://go/wvgerrit/103123
Bug: 161023174
Bug: 161621246
Test: WidevineDashPolicyTests#testL1RenewalDelay5S
Test: WidevineDashPolicyTests#testL1RenewalDelay13S
Change-Id: I16056d492bea4dd721984998b5cf38409fe3b055
