Breathing New Life into an Old IFE Server

Breathing New Life into an Old IFE Server


At IdeaNova, we work closely with our partners to provide excellent In-Flight Entertainment (IFE) solutions. We pride ourselves in the fact that we are not easily deterred and work diligently to solve customers’ problems.

In this post, we’ll detail the journey of the IdeaNova Engineering Team and the work they did to come up with a solution for a particularly challenging IFE deployment problem.

Decades ago 64-bit systems became commonplace, and even mobile devices switched to 64-bit CPU architectures. As a result, software support for 32-bit operating systems has been steadily dwindling such was the case for recent releases of Widevine License Server SDK’s which now only support 64-bit operating systems.

One of our clients had an older IFE system running on 32-bit Intel hardware with CentOS 6.5. Their existing DRM solution could not be upgraded to support the latest Android devices. Their request to us: would IdeaNova be able to help replace the DRM solution with a modern SDK allowing them to gain a couple more years from the existing hardware? Our response: we don’t know, but we will find out!

Approach #1: Virtualize

Our first thought: Could we run a 64-bit virtual machine on a 32-bit Linux system? While this may sound like a pretty wild idea, it is a viable approach in certain cases. In fact, we did exactly this with another customer. However, this requires that the CPU and BIOS support Intel VT-x instructions. Unfortunately, in this case ‘VT-x’ was not an option.

Approach #2: A Little Luck, A Lot of Hard Work

While contemplating the next move, we were fortunate: Widevine said they had a 32-bit Intel release of their latest SDK, and that we were welcome to try it out. Our team came up with a quick proof of concept and determined our existing license server build could be ported over to this architecture.

However, we had one constraint: the CentOS release was using a rather old glibc version (2.14) and Linux kernel (2.6.32). The Widevine SDK requires glibc version 2.28, which meant that we’d have to:

  1. Build a custom glibc and upload it to the server
  2. Patch our binary to use the custom glibc version. This can be achieved with patchelf, e.g. patchelf --set-interpreter <path to alternate glibc>/ --set-rpath <path to alternate glibc>

What’s more, glibc-2.28 no longer supported the Linux kernel 2.6.32. The last glibc version supporting the kernel was 2.24 when specifically instructed to compile against that kernel. Close, but no cigar.

Glibc has a particular versioning scheme that is detailed in How To Write Shared Libraries. The short story is that glibc functions are versioned and function versions can be observed with nm or objdump etc, tools. After some analysis, we came up with a list of 8 functions that were not present in our glibc. And we found functions relatively straightforward to polyfill. Our plan of attack started to form:

  1. Download glibc-2.24
  2. Patch the sources with our custom functions, plus other patches that increase the version from 2.24 to 2.28
  3. Compile with --enable-kernel=2.6.32 option
  4. Use the aforementioned patchelf approach to patch the binaries to use the custom glibc

After tweaking the process, chasing down bugs, and testing, this approach worked!

Other Notes

We recently converted some supporting software, such as our Inplay Multi DRM Proxy, from Java or node.js, to Go. A primary motivation was to take advantage of the Go rich standard library. Reducing the number of 3rd party dependencies to a minimum, helped us control our software supply chain better. We are much less vulnerable to issues such as Apache Log4j Vulnerability–which luckily did not impact us.

With Go, we found two great benefits. We no longer had to find recent enough node.js or JVM that would run on this dated system! And since Go binaries are static by default, the glibc version is not a consideration, unless the CGO feature is required.


While our IdeaNova Engineering Team’s journey was rocky at times, the knowledge we gained was great. We are happy with the results and most importantly, we gained another satisfied customer.