1842676 - [wmfme] add test for PlayReady key system

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, task, P2)

Comment 1

[Alastor Wu [:alwu]]

Attachment: Bug 1842676 - part1 : add test for PlayReady.

Comment 2

[Alastor Wu [:alwu]]

Attachment: Bug 1842676 - part2 : add MOZ_COUNT_CTOR/MOZ_COUNT_DTOR to track leaking.

See [1].

[1] https://searchfox.org/mozilla-central/rev/d45dd05bf412e7468b3770a52519e9d546d6325c/docs/performance/memory/bloatview.md#74-82

Depends on D183194

Comment 3

[Alastor Wu [:alwu]]

Attachment: Bug 1842676 - part3 : do not create CDM actor pair if we are not going to communicate with the remote process.

Currently whenever we create a WMFCDMImpl, it would always create a new
MFCDMChild/MFCDMParent. However, we won't always need those actors
because we can query the capabilities from cached result [1]

Therefore, we should only create CDM actor pair when we have a need to
communicate with the remote process, which can reduce unnecessary IPC
calls.

[1] https://searchfox.org/mozilla-central/rev/2d06b7d5fbfa7a31776389da87c5f895b80df8d9/dom/media/eme/mediafoundation/WMFCDMImpl.cpp#83-97

Depends on D183619

Comment 4

[Alastor Wu [:alwu]]

Attachment: Bug 1842676 - part4 : store the result for PlayReady HWDRM when querying the result com.microsoft.playready.recommendation.

AddressSanitizer reported a false alarm [1] about the UAF in
MFCDMChild. The acutal situation is we create two MFCDMChilds in the
same address, the first one is created for checking the capabilites for
'com.microsoft.playready.recommendation', and the second one is created
for checking the capabilities for 'com.microsoft.playready.recommendation.3000'.

The WMFProxyImpl creates a one-time use MFCDMChild to check the
capabilites, and our implementation would go through every key system to
get their configs [2].

The issue happens when we finish checking 'com.microsoft.playready.recommendation',
then we will check its hardware key system, which creates a new
MFCDMChild sharing with the same address of the previous one that is
just destroyed.

AddressSanitizer thinks that is an UAF, but it's not. To workaround this
problem, we would store the config for 'com.microsoft.playready.recommendation.3000'
when asking 'com.microsoft.playready.recommendation' with the hardware
secure flag because they are exact the same. By doing this, we won't
create a second MFCDMChild, because we can get the capabilities from
cached result.

[1] https://treeherder.mozilla.org/logviewer?job_id=422617141&repo=try&lineNumber=5092
[2] https://searchfox.org/mozilla-central/rev/2d06b7d5fbfa7a31776389da87c5f895b80df8d9/dom/media/eme/MediaKeySystemAccess.cpp#168-178

Depends on D183620

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/42cc5d4d7461
part1 : add test for PlayReady. r=jolin
https://hg.mozilla.org/integration/autoland/rev/7784e13807f4
part2 : add MOZ_COUNT_CTOR/MOZ_COUNT_DTOR to track leaking. r=media-playback-reviewers,jolin
https://hg.mozilla.org/integration/autoland/rev/1b022762162e
part3 : do not create CDM actor pair if we are not going to communicate with the remote process. r=media-playback-reviewers,jolin
https://hg.mozilla.org/integration/autoland/rev/39e6f7a75cd4
part4 : store the result for PlayReady HWDRM when querying the result com.microsoft.playready.recommendation. r=media-playback-reviewers,jolin

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/42cc5d4d7461
https://hg.mozilla.org/mozilla-central/rev/7784e13807f4
https://hg.mozilla.org/mozilla-central/rev/1b022762162e
https://hg.mozilla.org/mozilla-central/rev/39e6f7a75cd4