If you look around your home from time to time, you will generally not (or hardly) find any computer technology that is more than a few years old. Most of us buy new cell phones, tablets and notebooks every two or three years. Meanwhile, even desktop PCs, once found in every household, are becoming rare.

The situation is often different in the industry. The motto "never touch a running system" has formed an unholy alliance with cost efficiency and now also with the shortage of skilled workers. It is not unusual for many devices to still be running Windows XP today. In non-security-critical and non-networked areas, it can be argued that attackers still have to physically access the devices in order to compromise them.

Some financial institutes and insurance companies still use antique Unix-based systems. This fits in with the picture that many jobs for COBOL developers are still advertised in the financial sector today. But stone-age systems are still in use in other industries too. It wasn't that long ago that an administrator was being sought for the now 35-year-old Windows 3.11 for Workgroups operating system (Link).

What seems funny - or is simply cost-effective - brings with it two fundamental problems:

1. The further development of existing systems has a natural limit: ancient hardware and software cannot map newer features at all. Even with a lot of programming effort and a hands-on mentality, the iron wall of limited hardware resources remains. Maintenance is also becoming increasingly difficult. How easy is it to find a Windows 3.11 administrator today?
2. Legacy systems are a security risk that is no longer up to date or acceptable given the immense economic burden of cybercrime. Cynics argue that you only have to wait long enough for critical security vulnerabilities in legacy systems to be forgotten or to slowly harden due to a lack of equipment that is no longer available. Legislation at EU and subsequently national level has recently put a stop to this. Newer systems must have a basic IT security architecture that includes life cycle management.

The Y2K38 Problem

Now there is a problem - similar to the Y2K problem - in unixoid systems. It consists of the fact that in such systems, system time has been measured in seconds since January 1, 1970. It was therefore already known - at least theoretically - that the long data type required for storage would no longer be sufficient to represent the system time at some point, namely on January 19, 2038 at exactly 3:14 a.m. and 7 seconds (UTC). In the wild 70s, however, the problem still seemed a long way off and presumably nobody seriously assumed that a system based on Unix would still be in use in 2038. (Weren't flying cars and trips to the moon for everyone the generally accepted future back then?) As things stand today, we may be a few steps closer to flying cars in the form of eVTOLs, for example, and commercial space travel for private passengers no longer seems completely unthinkable, but many legacy systems are still in use.

Fortunately, there will most likely be no major problems for safety-critical areas. There are rigid tests and mandatory certifications, but it cannot be ruled out that some mobile devices (such as measuring devices) or even production facilities may still have a 32-bit architecture without a corresponding bug fix.

Operating Technicians on their Guard

Companies that are sensibly looking at costs and do not touch certain systems simply because they run reliably should nevertheless evaluate whether problems could occur. Failed batches due to devices that no longer do what they are supposed to are also an operational risk in terms of finances and delivery commitments. Indirectly, however, it could also affect safety-critical areas, for example if an old Geiger counter with an older 32-bit Linux is used. If this no longer measures reliably, security risks can arise that were not previously on the radar.

The good news: With ELinOS 7.2, system integrators have an embedded Linux at their fingertips that is highly up-to-date, provides a certifiable security architecture and is hardened by its own means and can be further hardened (e.g. via ASLR, cgroups and many other techniques that ELinOS provides as standard). With ELinOS 7.2, the year 2038 problem is also history and customers from the embedded sector can sleep peacefully in the knowledge that counting could be a problem again in 292 million years at the earliest.

Want to learn more and test ELinOS? Go to www.sysgo.com/elinos