1771336 - Consider manually loading GMP DLLs to avoid code integrity guard in Windows S

Status: NEW

(Core :: Audio/Video: GMP, task)

Description

[Jeff Muizelaar [:jrmuizel]]

https://github.com/fancycode/MemoryModule contains a dll loader that can load dlls from memory instead of a file. This avoids the code integrity checks and is able to successfully load and run gmp-openh264. (I confirmed this with a build running on Windows S).

Unfortunately, MemoryModule doesn't properly support TLS (https://github.com/fancycode/MemoryModule/issues/31) and this causes widevine to break. See http://www.nynaeve.net/?p=190 for a description of how TLS is supposed to work.

It may be possible to get TLS working (https://github.com/bb107/MemoryModulePP claims to) but it would likely be fragile (it relies on Windows internal implementation details) and may not be sufficient for getting widevine to work.

I also tried using LoadLibraryEx with LOAD_IGNORE_CODE_AUTHZ_LEVEL but that did not seem to turn off code integrity guard. (Various resources suggest that Code Integrity Guard is implemented in kernel space inside of NtCreateSection)

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Attachment: Manually load GMP dlls

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Attachment: Use LOAD_IGNORE_CODE_AUTHZ_LEVEL

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Given the lack of an easy option here it's probably not worth pursuing further unless we really want to get something working in S-mode

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I tried using MemoryModulePP but ran into https://github.com/bb107/MemoryModulePP/issues/10

Comment 5

[Jeff Muizelaar [:jrmuizel]]

https://github.com/bb107/MemoryModulePP/issues/10 has been fixed and we get further along in startup. Now I'm running into a crash accessing TLS in DllMain of libGLESv2.dll

Comment 6

[Andrew Osmond [:aosmond] (he/him)]

For what it's worth, I was able to successfully call LdrLoadDllMemoryExW on the most recent Widevine with a slightly modified test.exe that comes with MemoryModulePP, as well as call GetProcAddress for VerifyCdmHost_0, and it returned an address.

All I changed was for it to load widevinecdm.dll here into memory using ReadDllFile:
https://github.com/bb107/MemoryModulePP/blob/79f258b672f81c6ebbee1454335c4a4309d07ccb/test/test.cpp#L68

and change the symbol name to VerifyCdmHost_0 here, as well as a print to dump it:
https://github.com/bb107/MemoryModulePP/blob/79f258b672f81c6ebbee1454335c4a4309d07ccb/test/test.cpp#L83

The library integration is much more complicated though, so I have not yet made the attempt to build it with gecko to do a more sophisticated test.

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

Oh I also called LoadLibraryW on the dependencies first to get them into memory, since I assumed we could load system libraries still even in S mode:
https://searchfox.org/mozilla-central/rev/70fb2d2a702db4cb455d282be77ecfe9bdcea589/dom/media/gmp/GMPParent.cpp#1153

Comment 8

[Andrew Osmond [:aosmond] (he/him)]

Also worth noting that it only loaded with MmpTls, not LdrpTls.

Comment 9

[Andrew Osmond [:aosmond] (he/him)]

I believe LdrpTls is failing because:
https://github.com/bb107/MemoryModulePP/blob/79f258b672f81c6ebbee1454335c4a4309d07ccb/MemoryModule/MmpLdrpTls.cpp#L21

is incompatible with my newer build of Windows, so it doesn't find the necessary symbol to provide TLS.