I’m fundamentally against UEFI, against Secure Boot, against encrypted partitions and against a number of other modern obsessions. But let’s talk a bit about the way Microsoft recently broke GRUB. But, first things first.

What did Microsoft do?

I don’t dual-boot Windows and Linux since the times when Win7 was still supported. So I learned about this big Microsoft flop from the August 23 edition of the Risky Biz News newsletter.

Microsoft breaks dual-boot: Microsoft’s latest batch of security updates have broken dual-boot Windows and Linux systems. The issue has been traced to a security update that patched a two-year-old vulnerability in the GRUB bootloader. Affected systems can boot into Windows but not into their Linux OS. The issue impacts most of the major Linux distros, such as Debian, Zorin, Mint, and Ubuntu. [Additional coverage in ArsTechnica]

This breakage was caused by Microsoft’s updates of August 13, so why did Ars Technica report it on August 21? The Reg also reported it on August 21! Eventually, Microsoft acknowledged the issue and shared a temporary fix. But fixes were already available on Ask Ubuntu and on Linux Mint Forums.

This is the error that the affected users were shown upon boot:

Verifying shim SBAT data failed: Security Policy Violation 
Something went seriously wrong: SBAT self-check failed: Security Policy Violation

The marvels of Secure Boot. But we all want security, don’t we?

Ars Technica doesn’t do a good job explaining what Microsoft meant to do, but I selected a few comments, with the last two being more or less helpful.

antibolo:

Secure Boot was clearly designed for reinforcing Microsoft’s monopolistic hold on the x86 architecture by supporting Windows and Windows only. I’ll never understand why that is considered acceptable by the EU and various other government bodies.

panton41:

Except, you know, that’s not true. You don’t HAVE to use Microsoft’s keys, and if you’re doing Linux only you can purge the Microsoft keys from the TPM and have the Linux distro install its own. You can also just, you know, turn it off if you’re doing Linux only but, assuming your distro and hardware supports (nVidia on Linux famously doesn’t) it, then it’s just making your system less secure.

solarfalcon:

Where does Microsoft’s responsibility end and informed user consent begin? If the trust chain upstream of the operating system is broken, Microsoft isn’t really entitled to alter it without consent; this isn’t Copilot.

There can be any number of reasons why “I want my computer to work” supersedes “Windows worries about the parts of the computer that aren’t its responsibility”. Especially if “Secure Boot” isn’t supposed to be a thinly veiled power play by Microsoft.

justinclift:

justinclift:

ZygP said:
Did they test using the same people Boeing used to test the Starliner?

Yep. Both companies have outsourced their testing to the famously reliable organisation /dev/null.

Nikratio:

It was intended to close a 2-year-old vulnerability in GRUB, an open source boot loader used to start up many Linux devices.

This is a very misleading way to phrase it. It sounds as if Microsoft is attempting to update/patch grub.

I’d suggest changing the article to say something like “It was intended to prevent the loading of vulnerable grub versions.”

SittingDuc:

The exploit is, a computer with no Linux and with secure boot enabled, can have exploitable grub installed by an attacker .. somehow? .. and then that exploitable grub used to break secure boot and do naughty virus things to the Windows install. Computer with no Linux gets hacked by attacker who brings grub.

Microsoft’s patch is to reject grub during the secure boot of a system that does not have Linux and thus finding grub would be unexpected. So the goal is noble – prevent a boot chain that should not be present from breaking the Microsoft OS.

Unfortunately, the implementation leaves something to be desired; breaking a boot chain that should be present and I fully expect in a few weeks to hear the proposed fix doesn’t stop the exploit it was raised against.

fyo:

There are some confusions and misconceptions as to what Microsoft is doing.

As stated in the top promoted comment (link), Microsoft is not patching GRUB.

The article is a bit unclear as to what exactly Microsoft is doing and I’m not thrilled with the description of SBAT (the link provided does a better job). Basically, UEFI runs a bootloader located in the EFI System Partition, provided this bootloader is signed with a valid key. However, this signing can be a bit cumbersome with Microsoft “holding the keys to the UEFI kingdom” and a shim is often with Linux installations. This shim is signed with a valid key and proceeds to run the bootloader, using its own verification process. The Secure Boot Forbidden Signature Database (DBX) contains keys and hashes that UEFI will not run. However, adding keys can have non-trivial consequences since different UEFI modules can be (and are) signed with the same key. Hashes are a “default allow” policy and only target known bad modules – and are generally inefficient to do for everything (dbx size is extremely limited). Instead, an SBAT can be used to target whole generations of forbidden modules. Each EFI module has some metadata associated with it (also signed) that describes e.g. the vendor, product family, product name, module, version etc. A single SBAT entry would thus enable blocking of many different modules based on that metadata.

Microsoft’s aim was to prevent vulnerable versions of GRUB from being run. It is not entirely clear from Microsoft’s patch notes exactly how their SBAT is structured, so we don’t know what went wrong with this part – if anything. Clearly, the stated intention of not pushing the SBAT to systems dual-booting Linux failed, but considering the widespread reports of even new installs not working, it seems at least plausible that Microsoft’s SBAT is structured such that it blocks more than just vulnerable versions of GRUB.

On UEFI and Secure Boot

I’m pretty sure things are not clear enough, despite the above explanations. And, I’m sorry to say, but I hold the opinion that Microsoft shouldn’t hold the keys to the kingdom, yet they do. Who gave them this right?

UEFI is oligopolistic crap:

UEFI Forum, Inc. is an alliance between technology companies to coordinate the development of the UEFI specifications. The board of directors includes representatives from twelve promoter companies: AMD, American Megatrends, ARM, Apple, Dell, Hewlett Packard Enterprise, HP Inc., Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies.

Now you know who and why. When the IBM PC platform appeared in 1981, pretty soon it became generic, and for the next two decades, a plethora of hardware manufacturers were racing for your money. That was a strong, healthy competition, something that we don’t have anymore nowadays. Starting from the pretense of the intrinsic security vulnerabilities of the BIOS concept, to which we could add MBR’s limitations (now replaced by the GPT), they decided to replace the BIOS with a thing called UEFI.

The promoters include the few entities that create UEFI firmware (and that previously made BIOS firmware). “Promoter” is an elegant term for “cartel member.” But among regular “members” there are a good deal of contributors, including Canonical, Red Hat, and SUSE; “adopters” are all the entities that need to use UEFI. They might not want to, but they have to. I wonder how much they paid for this privilege.

So I disagree with Debian’s take on Secure Boot:

UEFI Secure Boot (SB) is a verification mechanism for ensuring that code launched by a computer’s UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process, before the operating system has been loaded.

SB works using cryptographic checksums and signatures. Each program that is loaded by the firmware includes a signature and a checksum, and before allowing execution the firmware will verify that the program is trusted by validating the checksum and the signature. When SB is enabled on a system, any attempt to execute an untrusted program will not be allowed. This stops unexpected / unauthorised code from running in the UEFI environment.

Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means the firmware on these systems will trust binaries that are signed by Microsoft. Most modern systems will ship with SB enabled – they will not run any unsigned code by default. Starting with Debian version 10 (“Buster”), Debian supports UEFI secure boot by employing a small UEFI loader called shim which is signed by Microsoft and embeds Debian’s signing keys. This allows Debian to sign its own binaries without requiring further signatures from Microsoft. Older Debian versions did not support secure boot, so users had to disable secure boot in their machine’s firmware configuration prior to installing those versions.

It is possible to change the firmware configuration to either disable SB or to enroll extra signing keys. This is not required when running standard kernels provided by Debian but may be useful to some users, for example when using custom kernel builds.

…

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.

SB is also not meant to lock users out of controlling their own systems. Users can enroll extra keys into the system, allowing them to sign programs for their own systems. Many SB-enabled systems also allow users to remove the platform-provided keys altogether, forcing the firmware to only trust user-signed binaries.

The fuck it ain’t. Of course it is an attempt to screw everyone. Why is Microsoft the issuer of the certificates? (Not on Apple hardware: Mac’s UEFIs have Apple-issued certificates.)

On shim:

Shim is a simple software package that is designed to work as a first-stage bootloader on UEFI systems.

It was developed by a group of Linux developers from various distros, working together to make SB work using Free Software. It is a common piece of code that is safe, well-understood and audited so that it can be trusted and signed using platform keys. This means that Microsoft (or other potential firmware CA providers) only have to worry about signing shim, and not all of the other programs that distro vendors might want to support.

Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for as a trust root for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust – the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.

The following diagram from Red Hat’s What is UEFI Secure Boot and how it works? might be of help:

How I understand things

With Secure Boot enabled, UEFI checks the digital signatures of the bootloader and of the kernel (and its modules too!) against a database of allowed signatures stored in the UEFI firmware. For this to happen, the following must be present:

  1. The Signature Database (DB): This is a list of trusted signatures or certificates. Only binaries signed with a key present in this database are allowed to execute.
  2. The Forbidden Signatures Database (DBX): This is a list of revoked or disallowed signatures. If a binary is signed with a key in the DBX, it is explicitly blocked from executing.
  3. The shim, a small, lightweight bootloader that acts as an intermediary between UEFI’s Secure Boot and the main bootloader (e.g. GRUB). The shim itself is signed with a trusted key that is present in the UEFI DB, allowing it to pass Secure Boot validation.

Concepts:

  1. The shim validates and loads the main bootloader, then the kernel, which might not be signed with a key in the UEFI DB (unless the OS is Windows).
  2. The shim contains its own certificate (a distro’s public certificate) database and uses it to verify the signature of the next-stage bootloader and of the kernel. By using a shim, Linux distros can be made compatible with Secure Boot without requiring that the kernel be signed by Microsoft’s key.
  3. The shim itself is signed by a key trusted by UEFI (usually Microsoft’s), and it can verify the next stage’s signature using the distribution’s own key.
  4. During the boot process, UEFI verifies, with shim’s help, that the bootloader’s (say, GRUB’s) and kernel’s signatures are in the DB and not in the DBX. If the signatures pass these checks, the system proceeds to boot.

😕 What I could not understand initially was this: why both DB and DBX? If a signature has to exist in the Signature Database (DB) to be accepted, why is there a need for a secondary Forbidden Signatures Database (DBX)? If it’s not in the primary DB, it would be rejected anyway!

To put it this way:

  1. If a system has an obsolete UEFI, it will not have an updated DBX. So if it trusts a binary based on the presence of its certificate in DB, it will keep trusting it.
  2. If a system has an up-to-date UEFI that blacklists the respective certificate in the DBX, that update should also remove the certificate from DB. This way, the check is redundant, as the validation fails twice: first, for not being (anymore) in DB; secondly, for being blacklisted in DBX.

💡 It has to do with granular control. DBX can be used to blacklist:

    1. Signatures, i.e. keys or certificates. As I said, eliminating them from DB, which is present in the same UEFI, has the same effect, so…
    2. Specific hashes, i.e. specific binaries. Now, it starts making sense to me. Even if a binary is signed with a valid key (one that is still in the DB), it can be blocked if its hash is listed in the DBX.

    The DBX can revoke specific binaries or certificates without affecting other binaries signed with the same key that might still be trusted. This provides more granular control than just removing a key from the DB.

    While this DBX-based mechanism can be used to block known malicious binaries from being loaded, it very much resembles a signature-based antivirus, something that is completely broken as a concept!

    Why would I want something akin to an antivirus in my BIOS? Sorry, in my UEFI?

    I then asked ChatGPT about revoking a specific binary, and here’s its answer:

    Suppose a specific version of GRUB has a security vulnerability. The hash of that GRUB binary can be added to the DBX, ensuring that even though the GRUB binary is signed by a trusted key in the DB, this particular version will not be allowed to run.

    Wow! This is exactly what Microsoft did when it borked the dual-boot!

    Read again the explanation by fyo.

    On my Acer laptop manufactured 2022-09:

    • UEFI’s MOK (Machine Owner Key) database, listed using mokutil --list-enrolled, only contained AlmaLinux’s keys.
    • UEFI’s DB (Signature Database), listed using mokutil --db, only contains 6 keys: 2 by Microsoft, 1 by Acer, 1 by Linpus, and 2 with unspecified issuers.

    Here’s a simplified output:

    [key 1]
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
Validity Not After : Oct 19 18:51:42 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011

[key 2]
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
Validity Not After : Jun 27 21:32:45 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011

[key 3]
Issuer: C=Taiwan, ST=TW, L=Taipei, O=Acer, CN=Acer Root CA
Validity Not After : Jul 10 03:45:15 2033 GMT
Subject: C=Taiwan, ST=TW, L=Taipei, O=Acer, CN=Acer Database
        
[key 4]
Validity Not After : Dec 31 16:00:00 2039 GMT
Subject: CN=DisablePW
        
[key 5]
Issuer: CN=ABO
Validity Not After : Dec 31 16:00:00 2039 GMT
Subject: CN=ABO

[key 6]
Issuer: C=TW, ST=Taipei, L=Taipei, O=Linpus, OU=Linpus, CN=linpus.com/emailAddress=helpdesk@linpus.com
Validity Not After : Apr 11 07:54:42 2048 GMT
Subject: C=TW, ST=Taipei, L=Taipei, O=Linpus, OU=Linpus, CN=linpus.com/emailAddress=helpdesk@linpus.com

    Microsoft’s 3rd Party UEFI CA certificate “Microsoft Corporation UEFI CA 2011” has been superseded by “Microsoft UEFI CA 2023” on more recent computers. And the “Microsoft Windows Production PCA 2011” certificate is exclusively used to sign the Windows boot loader.

    Even the expiration dates are absurd. Why is Linpus’s certificate valid until a random date in 2048, and the two anonymous ones until the end of 2039, whereas Acer’s own certificate expires in 2033, and Microsoft’s on two different dates in 2026?

    If I don’t update my UEFI until then, and if I have Secure Boot enabled, I wouldn’t be able to boot my laptop after June 27 (Linux) or October 19, 2026 (Windows)! (Well, I suppose Win11 would have applied a patch until then, right?)

    What I couldn’t be bothered to investigate is the additional SBAT (Secure Boot Advanced Targeting) mechanism that has been mentioned, and which uses additional metadata that GRUB and the kernel apparently need to include.

    GNU.org: 19.4 Embedded information for generation number based revocation: “The Secure Boot Advanced Targeting (SBAT) is a mechanism to allow the revocation of components in the boot path by using generation numbers embedded into the EFI binaries.” More details in: UEFI shim bootloader secure boot life-cycle improvements. Arch Linux also has some interesting tidbits.

    And thus, Secure Boot is crap…

    Why does it need to be so complicated? Why do I need to boot an antivirus? Why do I need to sign, to whitelist, or to fucklist something in Linux? I never asked for such shit! I was happy with BIOS and the MBR! (And LILO.) And why do I have to let Microsoft control my life and decide what I can and cannot boot?

    This is why I never have Secure Boot enabled on my systems. I don’t use any kind of disk encryption either. From what I know:

    • Win7 was the last version to support BIOS. Disk encryption was never a default option in Win7.
    • Win10 requires UEFI. If the system is old enough to lack TPM, no encryption is proposed.
    • If TPM is available, Win10 Home will use by default Device Encryption, which lacks a recovery key.
    • If TPM is available, Win10 Pro, Enterprise, and Education will use BitLocker, although theoretically not by default. From what I’ve seen, most OEM installations of Win10 Pro default however to using BitLocker.
    • If Windows has been installed with disk encryption, disabling Secure Boot will make it unbootable because “the chain of trust has been broken.”
    • Win11 requires TPM 2.0 and has BitLocker enabled by default, except on Win11 Home, which uses Device Encryption, similar to Win10 Home.

    So the poor sheeple have little choice. Windows means UEFI with Secure Boot enabled. And disk encryption in most cases.

    Surely enough, even on systems that only boot Linux, Secure Boot is usually enabled, especially when using mainstream distros. Many people also assume they need disk encryption.

    There are two major errors here, IMO:

    Regarding UEFI: The UEFI mafia should have broken the former IBM PC architecture into “consumer” and “business” hardware categories. Personal use of “personal computers” (duh) doesn’t need Fort Knox levels of security. Nobody would break into one’s house to install an infected BIOS.

    Regarding disk encryption: Same here. The sheeple don’t need 24/7 guarded security. Their laptops don’t hold the keys to Paradise. Those prone to have their laptops stolen while traveling can protect specific files by using encrypted file or folder vaults. They should also use a password manager instead of letting the browser store passwords. And, again, nobody is going to break into their houses specifically to steal their secrets from the unencrypted computer filesystems.

    Why is everyone behaving as if they were all CIA or MOSSAD agents?

    Why are the manufacturers treating each shitty $300-$400 computer as if it were a crucially important server?

    Until Win2k, there was no such thing as disk encryption in Windows. Yes, Windows NT 4.0 Server lacked disk encryption. Additionally, most UNIX-like OSes didn’t have encryption-aware filesystems either. And, guess what? All hell did not break loose! Yes, I know, there were much fewer computers and servers back then. But if the servers were not physically hijacked back then, why would your personal computer be physically targeted today by China or Russia? Physically means that someone needs to have physical access to it.

    Even those who backup often might experience a crash that leaves them with some files only in a copy on the internal storage device. What’s more important then:

    1. To have a CIA-grade computer whose encryption cannot be broken?
    2. Or to be able to boot a Linux live distro using a USB flash drive, and to access an NTFS partition and retrieve the files that couldn’t be saved elsewhere?

    I always set my priorities right. First thing, I disable Secure Boot. Then, no filesystem encryption whatsover.

    En passant, I don’t dual boot anymore.

    BONUS: Microsoft’s IPv6 patch

    The same August Tuesday patch has fixed a Windows TCP/IP Remote Code Execution Vulnerability, CVE-2024-38063, which is…

    …a zero-click, wormable remote code execution hole in Windows that requires no authentication and is exploited using IPv6 packets. It’s pretty bad; it’s a 9.8-out-of-10 on the CVSS severity scale.

    If someone can craft the correct IPv6 packets to send to your vulnerable Windows machine via the local network or the internet, they can take over that box, install malware or ransomware, steal data, and more. This happens at the TCP/IP stack level in the operating system.

    Nice. This is so severe, that this happened:

    As a mitigation measure for those who can’t immediately install this week’s Windows security updates, Microsoft recommends disabling IPv6 to remove the attack surface. 

    However, on its support website, the company says the IPv6 network protocol stack is a “mandatory part of Windows Vista and Windows Server 2008 and newer versions” and doesn’t recommend toggling off IPv6 or its components because this might cause some Windows components to stop working.

    Yeah, Notepad would stop working. Comments on The Reg:

    grubby --update-kernel ALL --args ipv6.disable=1

    Or just edit /etc/default/grub, then run update-grub. But yes to this concept, I do it on all my boxes.

    Dave Plummer, an individual I dislike, has elaborated on this Critical Windows Exploit: What You Need to Know, Explained by a Windows Developer. As usual, I don’t give a shit on people regularly speaking in front of a camera instead of writing a couple of paragraphs (monetizing and narcissism go well together, they’re both into the American spirit, and also, for younger people worldwide, in Gen Z’s fiber). But I found two relevant comments.

    By @Psilobite:

    The thing that really p**ses me off is that Microsoft has patches for Windows 10 versions 1507, 1607, and 1809 (all LTSB/C), Windows Server 2008 R2 ESA (Windows 7), and Windows Server 2008 ESA (Windows Vista). This means that basically Microsoft can patch all versions of Windows 10, Windows 7, Windows Vista, Windows Server 2008, and Windows Server 2008 R2, but they chose to only patch ESA, and for Windows 10’s many different versions, they only patched the latest + LTSB/C. For Windows 7 and Server 2008 R2, people can use an ESA bypass patch, that is if they can get it to work. For anyone not using the latest version of Windows 10 or an LTSB/C version, they have no option but to completely disable IPv6.

    Given the severity of the patch and that it affects every Windows version going back to at least Windows Vista, I find it inexcusable that Microsoft easily has the ability to make the patch work on all versions of these OS’s, but withheld such patches, making sure to only support the latest Windows versions, ESA, and LTSB/C, the same as they would do for say an everyday mundane feature or usability patch. But this isn’t that. This is something that can potentially allow any kind of malware to run on an affected system bypassing all security and spread through the Internet. In these days of ransomware and highly destructive malware, this is absolutely unacceptable behavior from Microsoft. Again, they have patches for all of these versions of Windows, and are choosing to withhold them, deliberately restricting who can patch their OS.

    For people who are running a version of Windows that doesn’t have a patch, it’s best to just completely disable IPv6. Don’t just clear the checkbox in Network Adapter settings as that isn’t enough. You need to add this registry setting as well: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters, add dword DisabledComponents and set to off, then reboot. Open a command prompt and run ipconfig /all and ensure that there is no IPv6 section.

    If you need IPv6, you can use Tor, as that will give you an IPv6 address, and bypass the affected Windows components (ipconfig /all in a command prompt will show no IPv6 section).

    There’s also 0patch, but it doesn’t have a patch for this problem, although it might in the very near future. But I believe this will only work for ESA and not for all the various versions of Windows 10 for which Micosoft is withholding patches.

    Well, that’s Microsoft for you.

    By @JouMxyzptlk:

    The problem is, at least for Germany, the number of ipv6 only services is rising. Other countries which never got a big ipv4 pool, like China as most famous example, are decades ahead in ipv6-only services. So turning it off is not that good.

    As far as Windows LANs, with Domain Controllers, are concerned: When ipv6 was active during dcpromo, don’t turn it off or you may have extra 20+ minutes to wait until you can logon. Most prominently happened with Small Business Server 2008 and SBS 2011.

    This time, I have to disagree. Every single ISP in Germany (and elsewhere) will give you an IPv4 and an IPv6. Here’s why:

    Despite the decade-long lamentations that we’re running out of IPv4 addresses, IPv6 is hardly needed.

    The explanation is simple. The stupid mantra about running out of IPv4 addresses assumed that all those over 30 billion network-connected devices worldwide (including smartphones, tablets, IoT devices, and whatnot) require a unique IPv4. They do not.

    Most such devices are behind a home router, or behind a company router. If you have 10 devices in your household, or 200 computers in your LAN at work, they all share a unique public IPv4.

    Most devices on planet Earth actually have an IPv4 in the range 192.168.0.0 – 192.168.255.255 (192.168.0.0/16).

    Then, some large enterprises would also have devices with IPv4 addresses in the range 172.16.0.0 – 172.31.255.255 (172.16.0.0/12).

    Finally, the data centers and your ISP would have devices with internal IPv4 in the range 10.0.0.0 – 10.255.255.255 (10.0.0.0/8).

    There is a thing called Network Address Translation (NAT) to map internal private IPs to external public IPs. Without NAT, your connection to the Internet through a router wouldn’t work. (There is also a thing called DMZ, and another one called port forwarding, should they be needed.)

    This is why, in most cases, IPv6 is not needd, and it can be disabled.

    OK, maybe in China, they’re really out of public IPv4 addresses. I don’t know about China. Who knows, maybe in India too. But here in the Western world, not really. Make this experiment with your smartphone:

    1. Disconnect from Wi-Fi, so that your cell operator is your ISP.
    2. Go to What Is My IP Address and check your IPv4 and IPv6.

    You will always have an IPv4 address. Surprisingly enough, some European cellular providers (the proper designation: mobile network operators, or MNOs) would only provide you an IPv4, but no IPv6, despite your device supporting of IPv6!

    Reality always beats propaganda. In his 2007 Nobel Peace Prize acceptance speech, Al Gore said, regarding the North Polar ice cap: “One study estimated that it could be completely gone during summer in less than 22 years. Another new study, to be presented by U.S. Navy researchers later this week, warns it could happen in as little as 7 years.” Seven years was 2014, ten years ago. About when we were supposed to have no free IPv4 addresses, I guess.

    You can very well live without IPv6.