The EXODUS: Windows Secure Boot Kills Linux on June 24th!

On June 24th, something is going to

happen that the mainstream technology

press has almost entirely ignored, that

Microsoft has buried in technical

documentation written for hardware

manufacturers rather than human beings,

and that will affect tens of millions of

people who have never heard the term

secure boot in their lives, and who are

going to wake up that morning to find

that their computer no longer works the

way it did the night before. Not slower,

not glitchier, not missing a feature

they occasionally used. For a

significant portion of the people

affected, their computer is simply going

to refuse to start. The operating system

they chose, the one they installed

deliberately, the one they configured

carefully, the one that runs their work

and stores their files and powers the

tools they depend on every single day,

is going to hit a wall. A wall that

Microsoft built. A wall that Microsoft

is enforcing through a mechanism so

deeply embedded in modern computer

hardware that bypassing it requires

technical knowledge most people do not

have,

and some cases cannot be bypassed at

all. That wall has a name. Microsoft

calls it a secure boot policy update.

The Linux community calls it what it

actually is. An existential threat to

the ability of non-Microsoft operating

systems to run on Microsoft-influenced

hardware. And the date it goes fully

into effect is June 24th.

By the time this video is over, you're

going to understand exactly what secure

boot is, what Microsoft is changing, why

the timing of this change is not

coincidental, who is affected, the real

consequences are for the tens of

millions of people who run Linux either

as their primary operating system or

alongside Windows, and what you can do

right now to protect yourself, protect

your system, and make an informed

decision before a decision gets made for

you by a corporation that has spent 40

years trying to ensure that the answer

to the question of which operating

system you use is always, inevitably,

unavoidably, Windows. Begin with a

number. 32.8 million. That is the most

conservative credible estimate of the

number of people worldwide who use Linux

as their primary desktop operating

system.

That number has been growing every year

for the past decade, accelerating

sharply in the past 3 years as

dissatisfaction with Windows 11's forced

hardware requirements, its mandatory

Microsoft account setup, its aggressive

AI feature rollout, and its escalating

data collection practices have pushed

millions of users toward alternatives.

Add to that number the many millions

more who run Linux in a dual boot

configuration alongside Windows, who

boot into Linux for development work or

privacy-sensitive tasks, or simply

because they prefer the experience. And

the total population of people affected

by what is implementing on June 24th is

not a small community of hardcore

technical enthusiasts operating at the

margins of mainstream computing. It is a

global population of ordinary people,

students, developers, small business

owners, researchers, writers, activists,

and privacy-conscious individuals who

made a deliberate choice to use software

that respects their autonomy, and who

are about to discover that the hardware

their software runs on is not as neutral

as they assumed. To understand what is

happening, you need to understand what

secure boot actually is, because the

name is doing a significant amount of

political work, and understanding the

mechanism beneath the name is essential

for understanding why this particular

change is so consequential.

Secure Boot is a feature of the UEFI

firmware, the low-level software that

runs on your computer's motherboard

before any operating system loads. It

was introduced as part of the UEFI

specification in the early 2010s, and it

was sold to the public and to regulators

as a security feature.

The stated purpose was to prevent

malicious software from inserting itself

into the boot process before the

operating system loads, a category of

attack called a bootkit or rootkit that

is genuinely dangerous and genuinely

difficult to detect and remove.

Secure Boot addresses this by requiring

that every piece of software involved in

the boot process, from the bootloader to

the operating system kernel, be

cryptographically signed with a key that

the firmware recognizes as trusted. If a

piece of boot software is not signed

with a recognized key, the firmware

refuses to load it, The the machine will

not start. That is the mechanism.

And in the abstract, as a security

concept, it is sound.

Cryptographic signing of boot components

is a legitimate security technique.

The problem that the problem that

critics raised in 2012 when secure boot

was first mandated for Windows 8

certification, and that has never gone

away, is the question of who controls

the keys. Because a cryptographic trust

system is only as trustworthy as the

institution that manages the root of

trust.

And in the case of secure boot on the

overwhelming majority of personal

computers sold in the world, the

institution that manages the root of

trust is Microsoft. Microsoft operates

what is called the Microsoft UEFI

certificate authority. This is the

organization that signs the keys that

firmware trusts. When a hardware

manufacturer wants to ship a computer

with secure boot enabled, they include

Microsoft's certificate authority

certificate in the firmware's trusted

key database. This means that anything

signed by Microsoft's certificate

authority will boot, and anything not

signed by it will not.

For Windows, this is straightforward.

Microsoft signs Windows, Windows boots.

For Linux, the situation has

historically been more complicated and

more fragile. And June 24th is the date

that fragility becomes a crisis.

Linux distributions have historically

navigated the secure boot environment

through a mechanism called shim. Shim is

a small bootloader signed by Microsoft's

certificate authority that acts as an

intermediary. It loads first because it

carries Microsoft's signature, and then

it verifies and loads the actual Linux

bootloader using Linux's own keys.

This chain of trust allowed Linux to

boot on secure boot enabled hardware

without requiring users to disable

secure boot entirely, and without

requiring Microsoft to directly sign

every Linux distribution. Shim was an

engineering solution to a political

problem, and it worked imperfectly and

with ongoing maintenance overhead for

over a decade.

What Microsoft is changing on June 24th

breaks shim. Not by directly attacking

it. Not by revoking the signature that

allows shim to load.

By implementing a new secure boot policy

layer, referred to in Microsoft's

technical documentation as secure boot

advanced targeting or SBAT, that adds an

additional revocation mechanism capable

of blocking specific versions of shim

and other boot components, even if those

components carry valid cryptographic

signatures.

The revocation list that Microsoft is

pushing through Windows Update on June

24th includes shim versions that the

overwhelming majority of currently

installed Linux distributions depend on

to boot. When that revocation list lands

on machines that have Windows installed

alongside Linux, the firmware will

refuse to load the affected shim

versions. The Linux boot process will

fail. The machine will display an error.

And for users who do not understand what

happened, the experience will be

indistinguishable from their computer

simply breaking.

Now Microsoft will tell you, and has

told the Linux community in response to

the backlash that erupted when

developers first analyzed the

implications of this change, that this

is a security update.

That the shim versions being revoked

have known vulnerabilities. That the

SBAT revocation mechanism is a

legitimate and necessary tool for

maintaining boot security.

And here is the uncomfortable truth

about that argument. It is not entirely

wrong. Some of the shim versions being

targeted by the revocation list do have

documented security issues.

The SBAT mechanism is technically sound.

Boot security is a real concern.

But the implementation of this change,

the way Microsoft has chosen to deploy

it, the timeline, the communication, the

complete absence of any meaningful

effort to ensure that the change does

not render dual boot systems unbootable,

tells you something important about

whose security Microsoft is primarily

concerned with. If Microsoft's genuine

priority were boot security across all

operating systems running on Windows

certified hardware, the company would

have coordinated with Linux distribution

maintainers months in advance to ensure

updated shim versions were deployed

before the revocation list went live. It

would have built detection into the

Windows Update process to identify dual

boot configurations and warn users

before applying changes that would break

their Linux installation.

It would have provided a clear,

prominent, plain language notification

to users of affected systems explaining

what was changing and what they needed

to do. Microsoft did none of these

things. The Linux community learned

about the June 24th deadline not from

Microsoft communications, but from

developers who read firmware

specification documents and update

manifests and reverse engineered the

timeline themselves.

The people most affected by this change

are the last people Microsoft told about

it. That is not what security

prioritization looks like. That is what

competitive prioritization looks like.

Linux is the primary alternative to

Windows on personal computer hardware.

It is growing.

Microsoft's market share is the thing

that grows when Linux's does not.

The mechanism that is being used to

implement this change happens to be a

security mechanism.

But the effect of the change is to make

Linux harder to run on the hardware

Microsoft influences. And the specific

implementation choices Microsoft made

guaranteed maximum disruption to

existing Linux users.

Those facts sit together and they do not

suggest coincidence. Let us talk about

who is specifically affected and how.

Because the impact is not uniform and

understanding your specific situation

determines what you need to do. If you

run Linux exclusively, no Windows

installation on the machine at all,

and you have already disabled secure

boot in your firmware settings, you're

not directly affected by the June 24th

update because the SPUR revocation list

is delivered through Windows update and

your machine has no Windows installation

to deliver it through.

However, you should still pay attention

to the situation because the revocation

list, once it exists and is deployed on

Windows machines, can propagate to

firmware on machines that were

previously Windows machines and whose

firmware retains the updated revocation

database even after Windows is removed.

If you run Linux in a dual boot

configuration with Windows on the same

machine, you are in the highest risk

category. Your machine has Windows

Update running. Windows Update will

deliver the SBAT revocation list on or

around June 24th. If your Linux

distribution uses a shim version on the

revocation list, your Linux installation

will fail to boot after the update. This

is the scenario affecting the largest

number of people and the one requiring

the most urgent attention.

If you run Windows only but have been

considering trying Linux, the June 24th

change raises the barrier to entry for

dual boot experimentation. And that is

worth understanding before you make any

hardware or software decisions.

If you are a developer or system

administrator managing Linux deployments

in environments where Windows is also

present, the implications extend beyond

your personal machine to every system in

your environment and the action plan

below applies at scale. Here's what you

need to do starting right now before

June 24th arrives. The first step is to

determine whether your Linux

distribution uses a shim version

affected by the revocation list. The

specific shim versions being revoked are

documented in a public GitHub repository

maintained by the Linux shim development

team and the major Linux distribution

forms, including Ubuntu, Fedora, Debian,

Mint, Arch, and Manjaro have all

published advisories in the past several

weeks detailing whether their current

stable releases are affected and what

the fix is.

Check your distribution's official

forums and security advisory pages for a

post specifically addressing the June

24th SBAT update.

If your distribution has released an

updated shim package that is not on the

revocation list, installing that update

before June 24th is the single most

important action you can take. The

second step is to back up everything on

your Linux installation right now today

before anything else. Use your

distribution's backup tools or live USB

environment running a tool like

Clonezilla to create a complete image of

your Linux partition. Store this on an

external drive that you disconnect and

physically set aside.

If the worst happens and your system

becomes unbootable on June 24th, having

a current backup means you lose hours of

recovery time rather than losing data.

The third step is to note your current

firmware settings before anything

changes.

Restart your machine now and enter your

UEFI firmware setup, typically accessed

by pressing F2, F12, delete, or escape

during startup depending on your

hardware manufacturer.

Navigate to the secure boot settings and

write down or photograph exactly what

you see. Which secure boot mode is

active? What keys are enrolled? Whether

there is a custom key option?

This information is your reference point

and you will need it if you have to

perform manual recovery. The fourth step

involves temporarily pausing Windows

update to give yourself time to

implement the other steps without the

revocation list landing before you are

ready.

Go to Windows settings, then Windows

update, then advanced options, then

pause updates, and set the maximum

available pause duration.

This buys you a window to ensure your

Linux shim is updated before the

revocation list arrives. Once you have

confirmed your Linux installation has an

updated shim, you can resume updates.

The fifth step is specific to users

whose Linux distributions have not yet

released an updated shim or whose update

repositories have not yet propagated the

fix.

In this situation, you have two options.

The first is to disable secure boot

entirely in your firmware settings,

which allows Linux to boot without any

shim verification chain at all.

Disabling secure boot does reduce one

layer of boot security, but for personal

computers not operating in high security

enterprise environments, the practical

security impact is modest and the

alternative, a non- booting Linux

installation, is worse. The second

option, more technically complex but

more security preserving, is to enroll

your own machine owner key in the

firmware and sign your Linux bootloader

with that key.

This requires using the mokutil command

line tool present in most Linux

distributions and following a process

that takes approximately 30 minutes and

is documented in detail on the Arch

Linux wiki and the Ubuntu community

documentation. Both are accurate guides

applicable to most distributions with

minor modifications.

The sixth step applies to anyone who

discovers on or after June 24th that

their Linux installation no longer

boots.

The recovery process begins with a Linux

live USB, a bootable Linux environment

on a USB drive that does not depend on

your installed system's shim. Boot from

the live USB, which will work because it

carries its own boot environment

independent of the revocation list

issue. From the live environment, you

can access your installed Linux

partition, update the shim package if an

updated version is now available for

your distribution, reinstall the boot

loader, and restore boot functionality.

The process is documented step-by-step

for every major distribution, and the

Linux community forums will have

distribution-specific

guides available by June 24th from

people who have tested the recovery

process.

You will not be alone in navigating

this, and the documentation will be

there when you need it.

There is a longer conversation that this

moment demands, one that goes beyond the

technical specifics of shim and SBAT and

revocation lists. And that conversation

is about control,

about who controls the hardware you paid

for, about who controls the firmware

embedded in that hardware, about who

controls the chain of trust that

determines what software your machine is

permitted to run. Secure boot, as

implemented on personal computer

hardware, answers all of those questions

the same way. Microsoft. Microsoft

controls the root certificate, Microsoft

controls what gets signed, Microsoft

controls what gets revoked. Microsoft

controls the timeline and the

communication and the implementation

choices that determine how that control

is exercised. And the consequence of

that control, demonstrated concretely on

June 24th for everyone paying attention,

is that Microsoft can make a decision in

Redmond, Washington, push it through a

Windows update mechanism on hundreds of

millions of machines simultaneously, and

render the Linux installations of tens

of millions of people non-functional

without asking permission, without

providing meaningful advance notice to

affected users, and without bearing any

of the consequences that those users

will face when they sit down at their

computers on the morning of June 25th

and find that something they built,

something they configured, something

they chose is simply gone.

That is what control over the boot layer

means in practice. It means that the

fundamental question of whether your

computer starts is not answered by you.

It is answered by Microsoft.

The Linux community has been fighting

this battle for over a decade since the

first secure boot mandates appeared. In

Windows 8 certification requirements and

critics warned that the mechanism would

eventually be used exactly this way.

For most of that decade, the fight

looked like paranoia to casual

observers.

Secure boot affected a small number of

edge cases. The shim solution worked

well enough. The theoretical threat

remained theoretical.

June 24th is the moment the theoretical

becomes concrete. It is the moment that

validates a decade of warnings from

developers and freedom advocates and

security researchers who argued that

giving any single company control over

the boot layer of the world's personal

computers was a decision whose

consequences would eventually be felt.

Those consequences are being felt now by

tens of millions of people who never

heard the warnings because the warnings

were written in technical language and

technical forums for technical

audiences.

The solution, the long-term structural

solution, is not a settings change or a

shim update. It is hardware that is

genuinely open, firmware that is

community controlled, and boot security

mechanisms that do not route trust

through a single corporate certificate

authority with its own competitive

interests in the operating system

market. Projects like Coreboot,

Libreboot, and the work being done by

the open firmware community point toward

that future. They are not the mainstream

yet. They require technical

sophistication to implement that most

users do not have, but they exist, they

are maturing, and the events of June

24th are the kind of concrete

demonstration of why they matter that

moves projects from niche to necessary.

For right now, for the 32 million Linux

users and the many millions more running

dual boot configurations who need to do

something practical before a deadline

that is measured in days, The action

plan above is your path through this.

Check your distribution's shim update

status. Install the update if it exists.

Back up your system completely. Note

your firmware settings. Pause Windows

update until your shim is confirmed

updated. If no update exists yet,

disable secure boot or enroll your own

key.

If you are reading this after June 24th

and your system no longer boots, use a

live USB to access your partition and

follow your distribution's recovery

documentation.

None of these steps are beyond the

capability of anyone who installed Linux

in the first place. None of them require

expertise beyond what you already

demonstrated when you chose to run a

non-Microsoft operating system on your

hardware.

What they require is time and attention

and the awareness that a deadline is

coming that will not wait for you to get

around to it. The exodus that gives this

video its name is not inevitable. It

does not have to be your story,

but it will be the story of every Linux

user who did not know this is coming and

did not act before it arrived. You know

now. Act before June 24th.

Your system, your files, and your

freedom to choose your own operating

system are worth 30 minutes of your

evening.