it is time for the next Core Update. Number 133!

To help us keeping those coming and to support our developers, please donate now!

Toolchain Updates

This update brings many updates on the core libraries of the system. Various changes to our build system are also helping us to build a more modern distribution, faster. The toolchain is now based on GCC 8.3.0, binutils 2.32 and glibc 2.29 which bring various bugfixes, performance improvements and some new features.

Although these might not be the most exciting changes, we recommend upgrading as soon as possible since this is essential hardening for backbone components of the user-space.

Disabling SMT - Intel's Security Issues

Disabling SMT has also been fine-tuned. It is now also being disabled on systems that are vulnerable to "Foreshadow". Probably all processors that are vulnerable to MDS are vulnerable to Foreshadow, too, so this won't affect many systems, but it is more correct to do so.

Increasing throughput of the new Intrusion Prevention System

As announced before, we were working on increasing the throughput of the IPS. This is being shipped now with this update and integrates a library from Intel which is optimised to perform pattern matching very fast on huge data sets. Its name is hyperscan.

This library comes in multiple versions which are all shipped at the same time and is being compiled with support for various CPU instructions which are enabled when the hardware supports them. Those are for example AVX2, AVX and of course all of the SSE series.

By utilising those optimised instructions, the processor can process more data by executing only one instruction which is a lot faster. We are soon going to release benchmarks, but first tests have shown that larger systems are benefitting hugely from this and even some smaller embedded processors gain slightly.

This feature is automatically configured and will always be enabled when supported.

Another change on the IPS is coming from Tim Fitzgeorge who investigated that the IPS was occasionally dropping some packets which it was not meant to without logging. The rule generation was patched accordingly so that won't happen any more and rules will automatically updated when installing this Core Update.


  • A long-standing bug in adding fixed DHCP leases has been fixed. Those are now saved right away on the first click, but it is possible to edit the entry.
  • An incorrect list of cipher suites was generated for IPsec connections when PFS was disabled. This updates fixes that and updates all connections with the correct settings.
  • ddns: Some new provides have been added
  • Package updates: bind 9.11.7, jansson 2.12, knot 2.8.2, linux-pam 1.3.1, monit 5.25.3, openssl 1.1.1.c, rrdtool 1.7.2, squid 4.7, strongswan 5.8.0, wpa_supplicant 2.8


New Packages

  • tshark A CLI version of Wireshark which is like tcpdump, but has better support for decoding captured packets.

Updated Packages

  • hostapd has been updated to version 2.8 which fixes various security vulnerabilities and other bugs
  • tor: some bugs that didn't allow the service to start after the last update have been fixed
  • wio: A problem which caused the IPFire system to unexpectedly shut down has been solved
  • miau, an IRC bouncer, which was unmaintained since 2010 has been dropped

This is another follow-up post on the Intel processor vulnerabilities. Yay. With more bad news. Yay!

Instead of a long build-up, I will just give you the point: 32 bit is broken

Well, is that really news? Not really. The real news is that Intel processors are broken - but you already know that. You also know that there are fixes around. Patches for the kernel. Disabling Intel(R) Hyper-Threading.

But what when you are running 32 bit x86 code?

We have a new page on the IPFire Web User Interface which shows the status of your hardware. For most people, this will be very blue like here. Most Intel processors have it all. If you are running an older Intel Atom processor you might have a dash of green in there, but generally every Intel CPU if affected by at least something.

These mitigations are not fixes. They literally mitigate the impact and make an attack virtually impossible. But there is still a very small likelihood that an attacker might be successful. That will never go away. The hardware is fundamentally broken.

The Lack of Mitigations on 32 bit architectures

In this post, I would like to highlight, that when you are using a CPU that is affected by Meltdown, you won't have any mitigations for it when running IPFire in 32 bit mode. In short: it is not patched.

Why is that? The Linux kernel just doesn't have mitigations for it. Instead of talking about why that actually is, I would to tell you the consequences of it: Your system is not secure. An attacker that is able to inject any code into the system will be able to run a Meltdown exploit and compromise your crypto material and be root.

This is by the way not a problem that is exclusive to IPFire. It affects all distributions.

As always, there is a bit of a workaround: If you are running into this problem, it is quite likely that you are running a modern processor, but with the 32 bit version of IPFire. The fix is to upgrade IPFire to 64 bit - which can only be done with re-installing the whole system (and restore a backup of course).

If you have a processor that is affected by Meltdown but does not support 64 bit (not sure if they even exist), then the only solution is throwing that box away. It is no longer secure hardware and therefore won't run as a secure firewall.

There you have it. Me telling you bad news again. There is nothing we can do for you here. It is your call now to become active and upgrade your installation. It might be painful, but you will have to do it.

The actual consequence for the IPFire project should be to pull the 32 bit version. That would be the right thing to do. It has become a second-class citizen in the Linux space and we knew that this would happen for quite some time now. Fixes will be - if at all - rolled out only very very slowly. For us, that means that we have to do more work to make this happen and I am becoming less and less interesting in doing that...

I am angry

I am personally feeling very exhausted about this whole topic. The time that we have spent on researching the vulnerabilities, assessing how severe they are for IPFire, what we can do about it. And of course finally implementing and rolling out fixes. Time that is literally wasted and would have been better invested on other things.

It is being made worse by some actors who spread wrong information, only half the information to make a certain vendor look better when it actually is really bad. I have not seen a single article in the press that has shed light on the whole problem and in detail. It is only headlines these days.

For us it feels a lot like we are now all cleaning up after a profit-hungry corporation that had nothing else in their mind but making profit. Money, money, money. It's a rich man's world.

Now, it seems that those problems are making Intel even richer. People are throwing away old hardware and buying new one with exactly the same (or more) vulnerabilities. Some have to compensate for the loss of performance and add more servers. More profit again.

I do not want to give any recommendation on what to buy now. I can only say what I would do and maybe that is useful to some people. I would like to say that I would no longer buy Intel products. But where are the alternatives? If I had to replace my laptop, there are probably not many with an alternative processor. Servers traditionally come with Intel processors, too. So I would probably end up buying Intel again and patching the hell out of it, hoping that we won't find more vulnerabilities that require expensive mitigations.

But I of course expect more problems to be found in the future. Jumping ship to AMD might be worth a try. But the next vulnerability might hit them, too. Even other architectures like ARM are partly affected.

Rant Over

Thanks for still being with me. Here are the take-aways from this post:

  • Intel processors are fundamentally broken. Mitigations are not fixes - no matter what their marketing tells you.
  • If you are running IPFire on 32 bit and your processor supports 64 bits and is affected by one of these vulnerabilities, reinstall now
  • Now!

Today, we have updated IPFire on AWS to IPFire 2.23 - Core Update 132 - the latest official release of IPFire.

This update brings you the new Intrusion Prevention System out-of-the-box as well as updates to the whole system.


This image is now available for new instance types. Amongst those are:

  • The new AMD-based instances t3a. Since Intel keeps struggling to address their security vulnerabilities, Amazon has introduced alternatives to the broken processor lines. There are now AMD EPYC-based instances available, with just the same performance, but at an even cheaper price!
  • nano instances: Although the recommended system requirements of IPFire are at least 1GB of memory, this instance size is very good for bastion hosts, testing and other installations that are not running many services. Therefore we made it available so that you can save money on not getting a too large instance. You can of course upgrade the system at any time!

How to update?

For all customers that are already running on the latest image, there is nothing to do here but to make sure that you have all updates installed on your instance.

Click here to go to IPFire on AWS