The nice thing about the SSE standards is that there are so many to choose from.

Like an opioid, SIMD starts off innocently enough. An architect partitions the existing 64-bit registers and ALU into many 8-, 16-, or 32-bit pieces and then computes on them in parallel. The opcode supplies the data width and the operation. Data transfers are simply loads and stores of a single 64-bit register. How could anyone be against that?

The IA-32 instruction set has grown from 80 to around 1400 instructions since 1978, largely fueled by SIMD.

https://medium.com/swlh/risc-v-vector-instructions-vs-arm-and-x86-simd-8c9b17963a31

I know that the article specifically says that ASLR was defeated, but I wonder if these other compiler/linker mitigations prevent (some of) these vulnerabilities (specifically fortify)?

The "hardening-check" perl script is available from EPEL on redhat platforms. Here I use it to report mitigations in an old FWTK component that I use for an internal legacy system.

$ hardening-check /home/fwjail/usr/local/etc/ftp-gw
/home/fwjail/usr/local/etc/ftp-gw:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: yes

$ rpm -qi hardening-check | grep ^URL
URL : http://packages.debian.org/har...

This best practice guide published by Hynek Schlawack is helpful.

I am currently running the following:

ciphers=ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:RSA+AESGCM:!aNULL:!MD5:!DSS

For https, I also step up to secp384r1. For non-https applications (primarily NFS), I step up to secp521r1.

You might consider a mix of RHEL-based distributions. From the commercial spectrum, these are the current options with the greatest flexibility. My advice is to try the conversion from both directions. Perhaps Rocky Linux will support such a conversion in the future.

Red Hat offers a "no support" server license for $350/year, which is the lowest licensing tier. Tiers with more capability and support are available for $800, and $1300.

https://www.redhat.com/en/stor...

Oracle has a larger range of tiers. The "no support" license is $120/year. Tiers with more capability and support are available for $500, $1200, $1400, and $2300.

https://www.oracle.com/linux/

Oracle Linux can be used in production without a paid license of any kind; Red Hat Linux cannot be used in this way for large deployments (excepting the new 16-seat license for a developer account).

Red Hat is aggressive with software audits; I have seen one.

Both Oracle and Red Hat now have complete toolsets to convert support between an installed CentOS/RedHat/Oracle OS.

Red Hat can now convert an installed CentOS or Oracle Linux to RHEL; previously a wipe and reinstall was required ("have fun reinstalling your system" is still on Oracle's CentOS site). The description looks much more thorough in replacing all possible packages with Red Hat versions:

https://access.redhat.com/arti...

Oracle does not replace CentOS or RedHat RPMs in their conversion (AFAIK), so it is much less violent on the platform changes.

https://github.com/oracle/cent...

https://linux.oracle.com/switc...

https://blogs.oracle.com/linux...

Let's look at the sales page, down at the bottom, buy support.

Basic Linux Support: "All Oracle Linux software is provided for free and can be downloaded from Oracle Software Delivery Cloud... There is no license cost associated with Oracle Linux. Pricing reflects $0 for license, and all charges are related to services."

Premier support: ditto.

Customers will notice if this policy changes.

Oracle has guaranteed indemnification. This is focused on SCO-type lawsuits, but also applies to itself.

"Provided you are a current subscriber to Oracle Enterprise Linux support services, if a third party makes a claim against you that any covered programs furnished by Oracle (“material” or “materials”), and used by you for your business operations infringes its intellectual property rights, Oracle, at its sole cost and expense, will defend you against the claim and indemnify you from the damages, liabilities, costs and expenses awarded by the court to the third party claiming infringement or the settlement agreed to by Oracle, if you do the following:

• Notify Oracle promptly in writing, not later than 30 days after you receive notice of the claim (or sooner if required by applicable law);
• Give Oracle sole control of the defense and any settlement negotiations; and
• Give Oracle the information, authority, and assistance it needs to defend against or settle the claim.

Oracle understands GPL quite well, and within their Linux distribution, they perform as expected.

If you use Oracle Database, then you are expected to pay for it. For the Enterprise edition, that is $47,500 per CPU core.

The Linux product is a rounding error on the database revenue, produced to achieve and maintain control of the entire software stack.

I have heard in the past that most Android kernel vulnerabilities are in device driver code (Qualcomm being perhaps the largest offender). Were it possible to run these drivers in userspace with reduced privilege, a great many exploits would not be possible. I found an old paper with some evidence for this.

Famous microkernels of the last decades have definite security advantages to monolithic designs, in the ability to reduce privilege and isolate critical components. Minix, QNX, and GNU HURD are likely the most well-known, some being less polished than others. Microkernels do suffer performance problems because of message-passing between isolated components if not carefully designed.

Google could have bought QNX and open-sourced it, and that might have been a more direct approach than designing a new microkernel from scratch. QNX has already implemented Android emulation. Google could have actually bought Blackberry and crowned it as the next Android had they wished.

For some reason, Google prefers to design a new microkernel. This is going to take a long time.

https://f-droid.org/en/package...

An app exists on F-Droid to shut down Bluetooth after a period of inactivity, with optional notification and delay settings.

This app is named Greentooth.

Yes, this is still in extended support.

$ uname -r
2.6.18-419.0.0.0.2.el5PAE

$ cat /etc/redhat-release /etc/oracle-release
Red Hat Enterprise Linux Server release 5.11 (Tikanga)
Oracle Linux Server release 5.11

$ $ORACLE_HOME/bin/sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Fri Aug 14 13:32:43 2020

Copyright (c) 1982, 2013, Oracle. All rights reserved.

SQL>

The Unbreakable Enterprise Kernel is supported on RedHat. It also works on CentOS.

$ rpm -qa | grep ^kernel | sort
kernel-3.10.0-1127.18.2.el7.x86_64
kernelcare-2.32-1.el7.x86_64
kernel-devel-3.10.0-1127.18.2.el7.x86_64
kernel-headers-3.10.0-1127.18.2.el7.x86_64
kernel-tools-3.10.0-1127.18.2.el7.x86_64
kernel-tools-libs-3.10.0-1127.18.2.el7.x86_64
kernel-uek-5.4.17-2011.5.3.el7uek.x86_64
kernel-uek-devel-5.4.17-2011.5.3.el7uek.x86_64

They also return support for many drivers that RedHat removes, both drivers (megaraid, aacraid) and higher functionality (BtrFS).

The goal of an adversary who desires to inflict maximum damage is to compromise the cooling system. Decay heat is produced even when all control rods are fully engaged, and is sufficient to rupture most (all?) currently operating reactors. Hopefully, these attacks have been carefully analyzed, and countermeasures employed. But I fear not.