search

xbmc / inputstream.adaptive

kodi inputstream addon for several manifest types
Other
452 stars 241 forks source link

Latest Widevine 4.10.2252.0 fails to load #678

Closed wagnerch closed 1 year ago

wagnerch commented 3 years ago

It appears Google may have changed the latest Widevine libraries, the size has changed by about 1M, and it is not linking all of the same libraries as it used to (perhaps some stuff is statically linked now). In any case these are the errors, but there isn't enough logging to know the issue. Also the dlerror() message is squashed and never bubbles up.

2021-05-09 20:29:53.661 T:4807 ERROR : AddOnLog: inputstream.adaptive: Unable to load widevine shared library (/storage/.kodi/cdm/libwidevinecdm.so) 2021-05-09 20:29:53.661 T:4807 ERROR : AddOnLog: inputstream.adaptive: OpenDRMSystem failed

Related issues: https://github.com/CastagnaIT/plugin.video.netflix/issues/1154

Working CDM:

13505.111.0/libwidevinecdm.so: linux-vdso.so.1 (0xbefbd000) /usr/lib/libarmmem-v7l.so (0xb6808000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb67df000) libm.so.6 => /usr/lib/libm.so.6 (0xb6776000) libdl.so.2 => /usr/lib/libdl.so.2 (0xb6763000) librt.so.1 => /usr/lib/librt.so.1 (0xb674c000) libnss3.so => /usr/lib/libnss3.so (0xb664f000) libnssutil3.so => /usr/lib/libnssutil3.so (0xb661c000) libnspr4.so => /usr/lib/libnspr4.so (0xb65e5000) libc.so.6 => /usr/lib/libc.so.6 (0xb64a6000) /usr/lib/ld-linux-armhf.so.3 (0xb6f66000) libplc4.so => /usr/lib/libplc4.so (0xb6f8f000) libplds4.so => /usr/lib/libplds4.so (0xb6f8b000)

Non-working CDM:

13816.64.0/libwidevinecdm.so: linux-vdso.so.1 (0xbedb9000) /usr/lib/libarmmem-v7l.so (0xb5dd7000) libdl.so.2 => /usr/lib/libdl.so.2 (0xb5dc4000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb5d9b000) librt.so.1 => /usr/lib/librt.so.1 (0xb5d84000) libm.so.6 => /usr/lib/libm.so.6 (0xb5d1b000) libc.so.6 => /usr/lib/libc.so.6 (0xb5bdc000) /usr/lib/ld-linux-armhf.so.3 (0xb6f78000)

matthuisman commented 3 years ago

Amazing. Thank you.

magnusja commented 3 years ago

Is there an easy way to install an older version of widevine to make it work on current Coreelec (19.1)?

matthuisman commented 3 years ago

Is there an easy way to install an older version of widevine to make it work on current Coreelec (19.1)?

Yes: https://github.com/CastagnaIT/plugin.video.netflix/issues/1154#issuecomment-837286703 But possibly will only work for next few days

magnusja commented 3 years ago

Is there an easy way to install an older version of widevine to make it work on current Coreelec (19.1)?

Yes: CastagnaIT/plugin.video.netflix#1154 (comment) But possibly will only work for next few days

Worked like a charm thanks!!!

vascobraga41 commented 3 years ago

Is there an easy way to install an older version of widevine to make it work on current Coreelec (19.1)?

Yes: CastagnaIT/plugin.video.netflix#1154 (comment) But possibly will only work for next few days

Worked like a charm thanks!!!

Just for your reference, latest nightlies in CoreELEC are prepared for old and new widevine. Everything works in both situations.

VGerris commented 3 years ago

Thanks for all the info shared here, a great read. Yesterday I could not find an issue for CoreElec so I just created : https://discourse.coreelec.org/t/latest-widevine-not-working/15909/2 . Now I see it's fixed in nightlies, when will it be in a release like 9.2.8? Perhaps it's good to reply on the forum link to not hijack the thread. Thanks

Oldschooler76 commented 3 years ago

Hello, I use RPI 3/4 once with Kodi 18.9 Libreelec 9.2.6 and once with Kodi 19.1 beta 3, also Libreelec. Can I expect the new Widvine version from 1.6.21 to run on both systems? I'm not really getting the hang of it about the future of the Widvine on Libreelec. Maybe someone here can explain to me exactly how to proceed. Thank you very much for your answers ....

horstle commented 3 years ago

LE9 will get an additional release 9.2.7 with support for the new Widevine. For LE10 beta/nightlies (currently) you need to add/modify a file as explained here: https://github.com/emilsvennesson/script.module.inputstreamhelper/issues/437#issuecomment-850355736

Oldschooler76 commented 3 years ago

Well that sounds very good, thank you very much ... At least now I know where I'm going ... For the L10 beta 3 it will certainly be included in the official version, right?

matthuisman commented 3 years ago

the older versions have now been revoked at midnight US Pacific Time

UPDATE: Seems ARM hasn't been revoked yet - just the other platforms 4.10.1679.0 still working for me on a Pi4 LibreELEC 9.2.6

Lookens commented 3 years ago

I see that, so now the only solution is to go on Kodi 19.1 ?

magnusja commented 3 years ago

I see that, so now the only solution is to go on Kodi 19.1 ?

Just use this to install an older version

Is there an easy way to install an older version of widevine to make it work on current Coreelec (19.1)?

Yes: CastagnaIT/plugin.video.netflix#1154 (comment) But possibly will only work for next few days

Worked like a charm thanks!!!

wagnerch commented 3 years ago

the older versions have now been revoked at midnight US Pacific Time

Does it actually fail with an error?

mediaminister commented 3 years ago

I tested with Linux x64 Widevine version 4.10.1582.2

You get a standard "Playback failed" in Kodi Player.

And the license server responds with http error 500

2021-06-01 22:15:05.053 T:12113   ERROR <general>: CCurlFile::FillBuffer - Failed: HTTP returned error 500
2021-06-01 22:15:05.053 T:12113   ERROR <general>: CCurlFile::Open failed with code 500 for https://widevine-license.vudrm.tech/proxy:

2021-06-01 22:15:05.053 T:12113   ERROR <general>: AddOnLog: inputstream.adaptive: License server returned failure
2021-06-01 22:15:05.053 T:12113   ERROR <general>: AddOnLog: inputstream.adaptive: License update not successful (no keys)

Someone should also test with ARM Widevine version 4.10.1679.0. I'm not sure if this version fails.

wagnerch commented 3 years ago

@mediaminister Well, that's unfortunate. Hopefully everyone that needs it has an update path with the current solution.

matthuisman commented 3 years ago

actually guys, 4.10.1679.0 still working for me on a Pi4 LibreELEC 9.2.6 So maybe they just revoked the non-arm platforms?

wagnerch commented 3 years ago

Oh, okay. That explains why there isn't a whole lot of noise. I can't say I am surprised that Google is giving preferential treatment to ChromeOS.

matthuisman commented 3 years ago

last night i didn't have access to ARM, just my x86_64 and saw they revoked. So assumed it had happened across all and went into "battle mode"

i think maybe because some of the chrome image updates were only pushed over the last 2 weeks. Not really enough time to suddenly block the users using the older version yet.

wagnerch commented 3 years ago

I imagine it will happen, searching the net it's pretty clear that those pirating streams are freaking out: https://forum.videohelp.com/threads/401717-How-are-you-going-to-respond-to-widevine-l3-decryptor-s-death-at-May-31st

Also, it seems they are not all revoking at the same time, so not sure what to make of that.

Lookens commented 3 years ago

I see that, so now the only solution is to go on Kodi 19.1 ?

Just use this to install an older version

Is there an easy way to install an older version of widevine to make it work on current Coreelec (19.1)?

Yes: CastagnaIT/plugin.video.netflix#1154 (comment) But possibly will only work for next few days

Worked like a charm thanks!!!

I have an older version but now its revoked but thanks šŸ‘

So now someone can help to know what to do ?

Portisch commented 3 years ago

I am not sure but maybe I got on the wrong place so I will post it also here: https://github.com/CastagnaIT/plugin.video.netflix/issues/1179#issuecomment-852918911

For me it looks like the new cdm lib may is unstable and produce kodi crash.

wagnerch commented 3 years ago

FYI, CE team found the original cause for the TLS issues, as tcmalloc was a hack that was causing stability issues. So you basically need 2 patches:

https://github.com/LibreELEC/LibreELEC.tv/commit/7fa2987e4e600a036aa9442cc084b47dfeb341e6 https://github.com/CoreELEC/CoreELEC/commit/c16cfa4bafb84007e59166d31166c04b1b7808a3

For Debian, using glibc-2.28, you also need to roll back these Debian patches, as they are known to cause issues with LLVM compiled objects like widevine: arm/unsubmitted-ldconfig-cache-abi.diff arm/unsubmitted-ldso-abi-check.diff

Many thanks to the @Portisch & CE team to help stabilize this option.

MastaG commented 3 years ago

Sorry to bump this issue. I'm running Fedora 34 on arm 32bit here, my glibc version is: glibc-2.33-14.fc34.armv7hl There's no way to load the new version of the library without patching glibc? For a distribution such as Fedora that's a bit cumbersome as you'd have to maintain the package with the 2 patches to not break the dependencies.

Portisch commented 3 years ago

Not yet, no. The TCMalloc method got proofed as unstable so there is no known alternative right now. Maybe the glibc developers do rewrite someday the dlopen process to be able to detect the needed alignment before loading the shared library.

You can try to directly preload the CDM lib by LD_PRELOAD for your binary to avoid the dlopen issue.

MastaG commented 3 years ago

glibc-add-support-for-SHT_RELR-sections.zip

I could try to hack the kodi startup script and add the LD_PRELOAD method yes. Pre-loading libtcmalloc_minimal doesn't work for me as it causes a segfault on Fedora 34.

I've also rebased the patches for glibc 2.33 and rebuild the spec file. It seems to work fine now. ./a.out CDM Version: 4.10.2252.0

MastaG commented 3 years ago

However as long as the patches aren't upstreamed... I'll need to keep patching glibc or setup some koji repo just for these two patches.. really annoying.

codonell commented 3 years ago

However as long as the patches aren't upstreamed... I'll need to keep patching glibc or setup some koji repo just for these two patches.. really annoying.

As a glibc developer I do not want you to have to patch your distribution. I work hard with downstream distributions to ensure ABI consistency (including Google). It is difficult to get a new ABI created, and I empathize with teams that want to roll out experimental features, but the cautionary tale here is that enabled experimental features that change ABI create heedless divergence and impact binary artifact reuse throughout the ecosystem.

We should engage with Google to determine how best to get their work upstreamed (https://sourceware.org/bugzilla/show_bug.cgi?id=27924#c3). I appreciate those of you that reached out downstream to Fedora to raise the issue.

MastaG commented 3 years ago

I completely understand this @codonell I basically got the same answer when I proposed the patches on RH's bugzilla. So I've created a copr repo which builds a slightly newer version of the package with those patches applied. https://copr.fedorainfracloud.org/coprs/mastag/glibc_widevine/

I hope to test it soon.

Portisch commented 3 years ago

I would wait a bit more time before upstream anything. Maybe Google unintentionally introduced this alignment and change it back on next release.

wagnerch commented 3 years ago

Below are deb packages for Debian Buster, they should work on Debian, Raspberry Pi OS, and OSMC as they are all derivatives of Debian Buster.

https://github.com/wagnerch/ppa

Take backups before adding the repository and updating your packages, use at your own risk, sending all of the warning signals :). If someone is willing to give it a test and provide feedback (what OS & Device) that would be useful to others.

matthuisman commented 3 years ago

So that will just update glibc (and dependencies) right? After an apt-get upgrade? Did you bump the glib version number up?

On Sat, 4 Sep 2021, 08:41 wagnerch, @.***> wrote:

Below are deb packages for Debian Buster, they should work on Debian, Raspberry Pi OS, and OSMC as they are all derivatives of Debian Buster.

https://github.com/wagnerch/ppa

  • I don't know if these packages actually work.
  • Some limited testing was done in the arm32v7/debian:buster Docker container on a Raspberry Pi 4 running Raspberry Pi OS 64-bit. That testing included compiling the testhead (somewhere above) and testing that it loaded the 2252 CDM and reported the version. I only use LibreELEC & CoreELEC for Kodi, so can't do any further testing.
  • I did test updated glibc packages with some of the patches a few months ago on Raspberry Pi OS Buster 32-bit in Chromium with Netflix, but just not these particular package builds.
  • I don't know if they work on older RPi1 devices since it was built in an arm32v7 container, I think RPi2 is arm32v7, and RPi3 and later is arm64v8.
  • I don't know if it works on the OSMC Amlogic devices like Vero4K/Vero4K+, but expect it would.
  • InputStream Helper will likely not automatically install 2252, so you may need to disable ISH updates and install the 2252 version of the CDM manually.

Take backups before adding the repository and updating your packages, use at your own risk, sending all of the warning signals :). If someone is willing to give it a test and provide feedback (what OS & Device) that would be useful to others.

ā€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xbmc/inputstream.adaptive/issues/678#issuecomment-912798598, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPQAKJRV7DIVYKSRQTCN7LUAEXIDANCNFSM44Q62UKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

wagnerch commented 3 years ago

@matthuisman Yes, it's still based on 2.28-10, just bumped the package version to 2.28-110.1. There are some other upstream changes on the buster branch that were never released, left those alone. apt update && apt upgrade should pull in and install the updates.

BTW, here are the source package changes: https://github.com/wagnerch/glibc-deb/compare/debian/2.28-10...buster-widevine

bender711 commented 3 years ago

The updated packages work in OSMC on a Raspberry Pi 3B.

I did follow the instructions in @wagnerch's repository, followed by a sudo apt full-update and a reboot Then I followed the instructions in @matthuisman's article to update the Widevine module.

One reboot later the playback of widevine-needing addons started working again.

samnazarko commented 3 years ago

Iā€™m following this (OSMC) and will update shortly.

matthuisman commented 3 years ago

For any OSMC users who can't wait for the official fix (or want to stick with EOL Kodi 18) the below commands in OSMC terminal will get you back in action Use at your own risk

sudo apt-get install gnupg
curl -s --compressed "https://wagnerch.github.io/ppa/buster/KEY.gpg" | sudo apt-key add -
sudo curl -s --compressed -o /etc/apt/sources.list.d/wagnerch-buster-ppa.list "https://wagnerch.github.io/ppa/buster/wagnerch-buster-ppa.list"
sudo apt-get update
sudo apt-get install --only-upgrade libc6
sudo reboot
horstle commented 3 years ago

@wagnerch Could you include "arm64tls" in the version string, so inputstreamhelper could easily detect compatibility with newer versions?

wagnerch commented 3 years ago

@horstle I am a bit reluctant to do this in a Debian-environment (the ecosystem is a lot less controlled than LibreELEC), as the VERSION macro directly ties into gnu_get_libc_version, which could be used in autoconf scripts or anything that probes for a specific version, or perhaps expects a certain pattern.

The environment variable was an elegant minimal impact solution, perhaps I could inject something via /etc/profile.d, not sure if systemd scripts will source in /etc/profile.d, probably someone could test it on a Raspberry Pi OS or OSMC device and report back? For reference, this is the environment variable I am referencing, it is used by ISH to know if it can install the 2252 CDM:

https://github.com/LibreELEC/LibreELEC.tv/blob/31963ca452b1245bd9573542dd2eaad8418e2f0d/packages/mediacenter/kodi/scripts/kodi-config#L48

Otherwise I would have to provide replacement init scripts, and not really interested in meddling that much, especially considering it sounds like OSMC will take a look at it in the next few days for Buster.

I am expecting that if Amazon and I think Disney+ has already dropped support for the older CDM than Netflix isn't far behind, and that would be the major streamers, probably at that point it would make sense to remove the checks in ISH?

horstle commented 3 years ago

Currently we're planning to keep the checks, but give the option to install on a seemingly incompatible system, so it would still be helpful to be able to detect it, but not really necessary. https://github.com/emilsvennesson/script.module.inputstreamhelper/pull/446

samnazarko commented 3 years ago

Otherwise I would have to provide replacement init scripts, and not really interested in meddling that much, especially considering it sounds like OSMC will take a look at it in the next few days for Buster.

I'm looking at it. I don't see an issue if we roll out our own libc -- provided that we keep the version the same as Debian Buster.

So if I understand correctly, we can do the following to make things work with Google's CDM libraries on Buster:

And if I understand correctly, on Bullseye, no such glibc patches are needed.

matthuisman commented 3 years ago

@samnazarko

Blaimi commented 3 years ago

So if I understand correctly, we can do the following to make things work with Google's CDM libraries on Buster:

* Build libc6 with SHT_RELR and TLS alignment patches
* Remove Debian patches:
arm/unsubmitted-ldconfig-cache-abi.diff
arm/unsubmitted-ldso-abi-check.diff`

correct, that's what I did

* Do we need to build / ship tcmalloc library?

Libwidevine needs libtcmalloc-minimal4 as a new runtime-dependency.

* Set some environment when starting Kodi (our launcher script is in /usr/bin/mediacenter) to inform IA/ISH that we are compatible with new Widevine libraries. It looks like LIBC_WIDEVINE_PATCHLEVEL=1 is all that is needed to inform Inputstream Helper scripts that we are patched.

Where did you get this variable from? All I found was that tcmalloc needs to be preloaded since https://github.com/emilsvennesson/script.module.inputstreamhelper/pull/443 for the detection in IA/ISH (e.g. with LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libtcmalloc_minimal.so.4). If the preload is not done, libwidevine works also but you'll see the warning on update/installation.

And if I understand correctly, on Bullseye, no such glibc patches are needed.

I don't know

matthuisman commented 3 years ago

@Blaimi Your reading "old info". things changed since then. It was found that caused issues. 9.2.7 LibreELEC used that method and was unstable. 9.2.8 switched to the new better way that doesn't need the preload

All that is needed is: https://github.com/xbmc/inputstream.adaptive/issues/678#issuecomment-913047151 (which simply installs patched glibc, and then updates to the latest widevine cdm)

Blaimi commented 3 years ago

Ah, OK. But is it still needed for runtime? ldd /home/osmc/.kodi/cdm/libwidevinecdm.so doesn't mention libtcmalloc so probably not?

EDIT: Tried it, works without the package :)

samnazarko commented 3 years ago

@matthuisman Thanks for clarifying. I'll work on this shortly.

samnazarko commented 3 years ago

@wagnerch Thanks for the sources and PPA. I am trying to build for OSMC (need to adjust versioning) and tried to do a basic build with:

apt-get update
apt-get -y install build-essential git devscripts equivs
git clone https://github.com/wagnerch/glibc-deb
cd glibc-deb
wget http://deb.debian.org/debian/pool/main/g/glibc/glibc_2.28.orig.tar.xz
cd debian
cp control /tmp/control
DEB_BUILD_OPTIONS=nocheck mk-build-deps -irt 'apt-get --no-install-recommends -yV' /tmp/control
debuild -b -uc -us

This is on an OSMC (armhf) system. I get:

echo -n "Build started: " ; date --rfc-2822
Checking that we're running at least kernel version: 3.2
Build started: Mon, 06 Sep 2021 04:54:12 +0000
echo "---------------"
---------------
cd build-tree/armhf-libc && \
    CC="arm-linux-gnueabihf-gcc-8 -no-pie -fno-PIE" \
    CXX="arm-linux-gnueabihf-g++-8 -no-pie -fno-PIE" \
    MIG="arm-linux-gnueabihf-mig" \
    AUTOCONF=false \
    MAKEINFO=: \
    /home/osmc/glibc-deb/configure \
    --host=arm-linux-gnueabihf \
    --build=$configure_build --prefix=/usr \
    --enable-add-ons=libidn,"" \
    --without-selinux \
    --enable-stackguard-randomization \
    --enable-stack-protector=strong \
    --enable-obsolete-rpc \
    --enable-obsolete-nsl \
    --with-pkgversion="Debian GLIBC 2.28-110.1" \
    --with-bugurl="http://www.debian.org/Bugs/" \
     \
     \
    --disable-mathvec \
    --with-headers=/home/osmc/glibc-deb/debian/include --enable-kernel=3.2 --with-selinux --enable-multi-arch
/bin/bash: line 1: /home/osmc/glibc-deb/configure: No such file or directory
make: *** [debian/rules.d/build.mk:66: /home/osmc/glibc-deb/stamp-dir/configure_libc] Error 127
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1182:

Am I missing something obvious?

Blaimi commented 3 years ago

You missed extracting the tar.xz. Debuild is not doing this automatically.

You can also try to apt source glibc and then replace the debian-directory with the one from wagnerch (which is in fact only the debian/patches directory and the Dockerfile and debian/changelog). This downloads the upstream glibc-package, places all files with their corrects names to the correct location and extracts them together. You should also not bypass the creation of the src-package with -b. Without the src-package, some checks are omitted.

wagnerch commented 3 years ago

@samnazarko Yeah, this is what I do:

mkdir src
cd src
wget -N http://deb.debian.org/debian/pool/main/g/glibc/glibc_2.28.orig.tar.xz

git clone -b buster-widevine https://github.com/wagnerch/glibc-deb/ glibc-2.28
cd glibc-2.28

xz -dc ../glibc_2.28.orig.tar.xz | \
   tar xf - --strip-components=1

docker build \
   --pull \
   -t arm32v7/debian/buster \
   debian

docker run -it --rm \
   -u $(id -u):$(id -g) \
   -v /etc/group:/etc/group:ro \
   -v /etc/passwd:/etc/passwd:ro \
   -v $(pwd)/..:/usr/src/ \
   -w /usr/src/$(basename $(pwd)) \
   arm32v7/debian/buster \
   dpkg-buildpackage -us -uc

If your going to use some other container other than Docker then replace the last 2 docker commands with:

apt-get update \
 && apt-get install --no-install-recommends -yV \
    build-essential \
    devscripts \
    equivs

mk-build-deps -irt 'apt-get --no-install-recommends -yV' debian/control

DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -uc -us

@matthuisman Summarized it all nicely, for bullseye I think you have to drop this patch (it was dropped in sid): arm/unsubmitted-ldconfig-cache-abi.diff

And of course the same 2 patches that were added. The environment variable can be set in the kodi systemd scripts via Environment directive, haven't tested it, but the *ELEC's are use a ExecStartPre script to set it.

wagnerch commented 3 years ago

@matthuisman Since your keep tabs on the fixes, the Raspberry Pi OS's fix will only work on Chromium. They didn't apply the TLS alignment patch, so Kodi and other browsers still will not work. I tested it this morning, and the test program fails for "cannot allocate memory in static TLS block".

Installing from Raspberry Pi repository:

root@6fbf064dab2c:/build# apt-cache policy libc6
libc6:
  Installed: 2.28-10+rpt1+rpi1
  Candidate: 2.28-10+rpt1+rpi1
  Version table:
 *** 2.28-10+rpt1+rpi1 500
        500 http://archive.raspberrypi.org/debian buster/main armhf Packages
        100 /var/lib/dpkg/status
     2.28-10 500
        500 http://deb.debian.org/debian buster/main armhf Packages
root@6fbf064dab2c:/build# LD_LIBRARY_PATH=. ./cdmtest
ERROR: ./libwidevinecdm.so: cannot allocate memory in static TLS block

Installing from my repository:

root@6fbf064dab2c:/build# apt-cache policy libc6
libc6:
  Installed: 2.28-110.1
  Candidate: 2.28-110.1
  Version table:
 *** 2.28-110.1 500
        500 https://wagnerch.github.io/ppa/buster ./ Packages
        100 /var/lib/dpkg/status
     2.28-10+rpt1+rpi1 500
        500 http://archive.raspberrypi.org/debian buster/main armhf Packages
     2.28-10 500
        500 http://deb.debian.org/debian buster/main armhf Packages
root@6fbf064dab2c:/build# LD_LIBRARY_PATH=. ./cdmtest
CDM Version: 4.10.2252.0
matthuisman commented 3 years ago

oh, thats slightly annoying! So many edge cases to track

XECDesign commented 3 years ago

I can sort out Raspberry Pi OS. Is this all that's needed for the TLS fix?

https://github.com/LibreELEC/LibreELEC.tv/blob/libreelec-9.2/packages/devel/glibc/patches/arm/glibc-tls-libwidevinecdm.so-since-4.10.2252.0-has-TLS-with.patch

Anything else that should be added?