[HN Gopher] Linux and Secure Boot certificate expiration
___________________________________________________________________
Linux and Secure Boot certificate expiration
Author : pabs3
Score : 219 points
Date : 2025-07-18 03:53 UTC (1 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| crinkly wrote:
| So is it a possibility that a grub update breaks an existing
| bootable node? That worries me as I have a couple of Linux
| desktops in the field which I can't remember if secure boot is
| enabled on.
| jeroenhd wrote:
| If users don't update their keyrings or firmware (through
| fwupdmgr for instance), Grub will probably stop booting with
| secure boot on when the certificate expires.
|
| If users update Grub once the old certificate is no longer used
| to sign the bootloader without updating their keyrings or
| firmware, Grub will probably stop booting with secure boot on
| when the certificate expires.
|
| If users do update their systems and software, Grub will keep
| working.
|
| Not updating is not a solution, unless the motherboard
| manufacturer really fucked up and doesn't validate the
| expiration date.
|
| Luckily, fwupdmgr is integrated in the GUI updater tool on just
| about any Linux distro I know. As long as users don't ignore
| the "there are system updates available" popup and as long as
| the desktop vendor put out bare basic software support, things
| will probably go down fine.
| zozbot234 wrote:
| > Not updating is not a solution, unless the motherboard
| manufacturer really fucked up and doesn't validate the
| expiration date.
|
| The article mentions that most motherboards will probably not
| validate the expiration date. There is a residual concern
| that new versions of the Shim will not be signed with the
| expired key, and thus be unbootable on hardware that doesn't
| accept the new key.
| greatgib wrote:
| It's totally crazy that we have to go through Microsoft to sign
| things to be able to have our OS run on third parties computers,
| and that Microsoft manage to win about this so easily as it was
| never seriously challenged.
| whatagreatboy wrote:
| Only legal requirements can change it. Nowadays, the mokutil is
| good enough that linux users can build a good tool around it to
| automate registration at boot that should ease some pain. But
| otherwise, it is a big mess and still needs legal requirement.
| riedel wrote:
| The EU should step in and make sure that any critical OS
| attestation is taken out of the hands of the big players.
| Look at GrapheneOS is being denied Google Play Integrity [1]
| on pretty much no grounds with large consequences. Such
| security infrastructure is to easily abused to put bias into
| the market. On the other hand funding is needed to
| professionally run this stuff.
|
| [1] https://discuss.privacyguides.net/t/grapheneos-is-taking-
| act...
| nine_k wrote:
| Basically every x64 computer is intended to be able to run
| Windows. Hence MS had to be involved, and I suppose nobody else
| with serious money wanted the burden.
|
| AFAICT you can still disable Secure Boot in most UEFI firmware,
| and boot anything you like (or not like, if an attacker tampers
| with your system).
| oakwhiz wrote:
| We don't even reap the benefits of autocratic decisions from
| Microsoft in this area. Boards always come out with things
| like messed up ACPI, etc.
| p_l wrote:
| Boards' ACPI etc. is still better than what it would be
| without "certified for Windows" (whatever name of the hour
| is) programs
| blkhawk wrote:
| Secure boot belongs to a class of security that while clearly
| giving a theoretical benefit in practice it falls far short
| of providing any benefit whatsoever at least to the user of a
| system. Its introduction was mostly part of a wider (probably
| partially defunct and failed regarding mobile x86) strategy
| to lock down the PC so the Microsoft store and purchased apps
| through it would be more secure from the end-user. Secondary
| was in my opinion better security for handheld phones and
| tablets running x86 but there the "App store" aspect is even
| more clear.
|
| "attacker tampers with your system" does not happen at least
| in the way you think it does or it does not protect you
| against meaningful attack at all.
| pdimitar wrote:
| What kinds of attacks was Secure Boot designed to mitigate?
| Is it the evil maid attack? Or an accidentally ran with
| `sudo` program can indeed screw your entire boot process
| and inject rootkits etc.? Or is it something else?
| jeroenhd wrote:
| Evil maid and rootkits, mostly. It's also part of the
| trust chain that unlocks an encrypted disk without having
| to enter a password.
|
| On Windows, secure boot has worked pretty well when it
| comes to rootkits. MBR rootkits were trivial to write,
| but UEFI rootkits require UEFI firmware changes or
| exploiting the bootloader process itself, both of which
| are much more complex. If malware uses the Linux shim,
| the TPM will notice and refuse to provide the Bitlocker
| key, so your computer won't boot without going to the IT
| office and asking for the recovery key (which should
| prompt more investigation).
| blkhawk wrote:
| That is sorta the rub - the treat profile "evil maid" is
| mainly governmental actors for most people even for Orgs.
| Your example shows mostly how an org can secure their own
| devices against casual misuse by unprivileged users. This
| does not help against any serious attack. It only
| protects against stuff you don't need to worry about
| generally.
| cesarb wrote:
| > What kinds of attacks was Secure Boot designed to
| mitigate?
|
| Boot sector viruses, or their modern equivalents.
| Basically, anything which injects itself into the boot
| chain before the antivirus can start; after that point,
| the antivirus is supposed to be able to stop any malware.
| That is, they wanted to prevent malware from being able
| to hide from the antivirus by loading before it.
| danudey wrote:
| Another example: a custom kernel build or kernel module
| that backdoors your system or steals data at the kernel
| level. Secure boot provides the opportunity for a chain
| of trust that goes from the firmware manufacturer all the
| way down to your individual kernel modules.
|
| The firmware validates the shim. The shim validates the
| boot loader. The boot loader validates the kernel. The
| kernel validates the kernel modules.
|
| Once you have that chain of trust, you can also add in
| other factors; encrypt your disk using a key, seal the
| key in the TPM, and lock that key behind validation of
| the firmware and the boot loader. Your system boots,
| those different components are measured into the PCRs,
| and if the combination is correct the key is released and
| your disk can be decrypted automatically. Now if someone
| boots your system using a different firmware or boot
| loader, the TPM won't release the key, and your disk
| can't be decrypted except by someone with the passphrase,
| recovery key, etc.
|
| Without secure boot, you can't trust that any of those
| components aren't reporting falsified measurements to the
| PCRs, lying to the TPM, and getting access to the key to
| decyrpt your disk despite booting from a compromised USB
| drive. That, of course, means you can just encrypt your
| disk using only a passphrase that you manually enter, but
| for a lot of users (sadly) that's too complex and they'll
| choose not to use disk encryption at all.
|
| Case in point, TouchID and FaceID are seen as
| alternatives to using a PIN or passphrase to unlock your
| iPhone, but they're actually meant as alternatives to not
| locking your phone at all - a way to make device security
| transparent enough that everyone will use it. Without a
| secure chain of trust from the firmware to the kernel,
| that's not really an option.
| magicalhippo wrote:
| > Or an accidentally ran with `sudo` program can indeed
| screw your entire boot process and inject rootkits etc.?
|
| The more realistic scenario would be exploiting a
| privilege escalation bug. Of which there have been and
| will be plenty of on both Windows and Linux.
| msgodel wrote:
| Anything that locks you out of your own computer is at
| absolute best an availability failure but more often than
| not forces you to use compromised system software.
| somat wrote:
| MS did not "Have" to be involved. The problem is that doing
| it right is hard, not hard as in "it was tricky to figure it
| out but once we did everything works" but hard as in "every
| single user now has an additional impossible to remember key
| they have to keep track of or they get locked out of their
| system", basically the mother of all support nightmares. so
| Microsoft took the easy(perhaps realistically, the only) way
| out. they said "we are not going to have the end user own
| their keys, we will own the keys"
|
| Honestly I wish they(where they is them that designed this
| whole broken system) did it it right. On first boot you would
| set up some keys, now you are your own trust root, and when
| you you want Microsoft to manage your system, perfectly
| reasonable, managing systems is scary, you sign their keys
| and add them to the store. The problem is at a low level it
| all sort of just works, but nobody want to design that user
| interface. nobody wants to write the documentation required
| to explain it to joe random user. Nobody wants to run the
| call center dealing 24/7 walking people through a complicated
| process, patiently getting them unstuck when they loose their
| keys, explaining what a trust root is and why they now have
| to jump through hoops to set one up.
|
| I like to believe that had they done it right initially, the
| ui would have been molded into something that just works and
| the client base would also get molded into expecting these
| key generations steps. But I am also an optimist, so perhaps
| not and it is exactly as scary and thankless a task as I
| described above. But we will never know, Microsoft took the
| easy way out, said we will hold the keys. And now you are a
| serf on your own machine. Theoretically there is a method to
| install your own keys, and it may even work, but the process
| is awkward(never really being meant for mass use) and you are
| dependent on the vendor to care enough to enable it. Many
| don't.
| sugarpimpdorsey wrote:
| It makes more sense if you view it for what it is: Honest
| Satya's Certificate Authority.
|
| Microsoft showed they can semi-competently run a PKI. The end.
|
| Now had the Linux folks stepped up to the plate early on,
| instead of childishly acting like Secure Boot was the computing
| antichrist, the story might be different. But they didn't. We
| only have shim because some people at Red Hat had the common
| sense to play ball.
| flomo wrote:
| Maybe this isn't a great take, but RedHat/LKF/etc could
| obviously run a 'semi-competent' PKI, and probably should be.
| But doing so would allow PC vendors to cleanly segment
| machines between Windows and Linux (+$$), so perhaps it made
| the best sense to lay-low and use MS infrastructure for this.
| danudey wrote:
| Can easily imagine companies like Dell selling you a system
| with Ubuntu preinstalled but without Windows signing keys
| so you can't run Windows on an Ubuntu laptop (or vice-
| versa) with Secure Boot on an unmodified system.
|
| Not out of malice, necessarily, but at least incompetence.
|
| Likewise, having Microsoft signing the shim also means that
| any Linux installation with the signed shim can install on
| any system that supports Windows, whereas if RedHat had
| their own 100% comptent, rock-star PKI then a huge
| proportion of systems sold today would not be able to run
| Linux unmodified because the manufacturers wouldn't bother.
| sugarpimpdorsey wrote:
| This isn't really true.
|
| MS uses three separate CA's to sign Windows boot loaders,
| third party bootloaders (including Linux bootloaders) and
| UEFI Option ROMs.
|
| In theory, no manufacturer has to install all three as
| trusted. But it makes no business sense to do so - why have
| two separate hardware SKUs for the sole purpose of lock-in?
| Once word got out no one would buy from that manufacturer.
| littlestymaar wrote:
| > Now had the Linux folks stepped up to the plate early on,
| instead of childishly acting
|
| This kind of victim blaming gets annoying very quick, as if
| the Linux ecosystem had any leverage at all on PC
| manufacturers...
| sugarpimpdorsey wrote:
| > as if the Linux ecosystem had any leverage at all on PC
| manufacturers...
|
| Linux has 63% of the server marketshare, which is where
| Secure Boot and the whole chain-of-trust has utmost
| importance. Of course they have leverage.
|
| Do you think overall Secure Boot is more important in the
| context of securing your bank's servers, or some porno jack
| machine throwaway laptop?
| robin_reala wrote:
| Reference:
| https://bugzilla.mozilla.org/show_bug.cgi?id=647959
| ACCount36 wrote:
| Secure Boot is the computing antichrist, and Linux folk were
| 100% right to rally against it. As well as a whole bunch of
| other "Trusted Computing" garbage.
| froh wrote:
| mind to elaborate?
|
| I'd love to know if my machine has been compromised with
| early boot stage "meta-hypervisor" or not.
|
| the promise of secure boot and trusted computing is
| backdoor-free boot.
|
| what is in your eyes evil and garbage about that?
| ACCount36 wrote:
| Who controls the fucking certs?
|
| "My computer was compromised with an early boot stage
| hypervisor backdoor" happens basically never. It's an
| attack vector that exists almost entirely in the minds of
| infosec fucktards.
|
| "My brand new device ships with vendor-selected boot
| certificates that can't be changed, can't be overridden,
| and control what software I can install onto my own
| device" happens with every other smartphone, gaming
| console, car, and even some PCs.
|
| "Trusted Computing" is, and always was, about making sure
| that the user doesn't actually own his device. This is
| the real, tangible attack vector - and the target of this
| attack is user freedom and choice.
| flexagoon wrote:
| > Who controls the fucking certs?
|
| Cert authorities, just like in case of SSL. Is SSL also
| an evil technology designed to take away freedom from the
| internet?
|
| > vendor-selected boot certificates that can't be changed
|
| That's a lie. Certain drivers are signed with a specific
| key, and they can only be used when this key is
| installed, which makes sense. The same thing happens with
| SSL - if you remove pre-installed CA certs from your
| device, HTTPS sites will stop working. However, nothing
| is stopping you from adding your own keys to the system
| and signing your own software with it.
|
| > happens with every other smartphone, gaming console,
| car, and even some PCs
|
| How often are you trying to install custom drivers on a
| smartphone, console or car? Why would you have secure
| boot issues on those?
|
| > the target of this attack is user freedom and choice.
|
| Which is exactly why users have the freedom and choice to
| just disable Secure Boot?
| ACCount36 wrote:
| Take an iPhone or a Switch. Then disable Secure Boot on
| it. Good fucking luck.
|
| The reason why Apple or Nintendo go out of their way to
| make this impossible isn't user security. It's the
| "security" of their 30% App Store cut.
|
| Out in the wild, Secure Boot exists to "secure" vendor
| revenue streams - and PCs are the only devices where it's
| even possible for the user to disable it. Most of the
| time.
|
| What's happening in smartphone space is enough of a
| reason to treat Secure Boot on PC like an ongoing attack.
| The only reason why there are still legitimate ways to
| disable or adjust it is that most PC manufacturers don't
| have their own app store.
| tempnew wrote:
| Freedom vs safety should be contextual. I'm not free if I
| don't have choices and secure boot is a choice. Having it
| improves both my freedom and security somewhat. I want
| both unlocked and locked hardware, for different
| purposes.
| ACCount36 wrote:
| Secure Boot is almost never a choice. It's just something
| a hardware vendor hits you with, whether you like it or
| not.
| tempnew wrote:
| It's a choice I make all the time. I disabled it on one
| of my computers just last night. I'll probably turn it
| back on today. It's easy to toggle.
| ACCount36 wrote:
| Now do that on your smartphone. And then on your smart
| watch. And then on your gaming console.
|
| Secure Boot being "a choice" on PC is an exception, not
| the norm. On just about every other device, the vendor is
| going to take a boot, shove it up your ass, and say "it's
| there to make your ass more secure" if you complain.
| Y_Y wrote:
| Secure Ass-Boot is revolutionizing device security.
| zozbot234 wrote:
| > Which is exactly why users have the freedom and choice
| to just disable Secure Boot?
|
| There's some x86 hardware in the wild where the option to
| disable Secure Boot does not work. Which is part of the
| reason why Shim exists in the first place - it allows you
| to boot unsigned code with the machine owner's consent,
| even with Secure Boot enabled.
| speeder wrote:
| I had a Windows 8 laptop like this. Not only that, it
| rejected Shim too. Never managed to install Linux on it.
|
| Weirdly I had to leave secure boot option turned off too
| after a while, because more and more games started to
| have issues with the nVidia GPU. There was a RPG I forgot
| the name, isometricish that would outright crash if
| secure boot was turned on.
| serbuvlad wrote:
| > Is SSL also an evil technology designed to take away
| freedom from the internet?
|
| If it were not for Let's Encrypt, YES!
|
| Secure boot would not be a problem if it were trivial to
| enroll keys. Give me a big message like:
|
| "The OS you are trying to run is signed by an unknown key
|
| sha256:whateverthefuck
|
| IF YOU ARE NOT RUNNING AN INSTALLER YOU ARE MOST LIKELY
| CURRENTLY BEING ATTACKED AND SHOULD NOT PROCEED.
|
| If you are running an installer VERIFY THE KEY with the
| one your OS vendor gave you.
|
| Proceed? (Add the key as trusted)
|
| yes NO"
| drewg123 wrote:
| Amen. This is how it _SHOULD_ work.
| blendergeek wrote:
| > How often are you trying to install custom drivers on a
| smartphone, console or car? Why would you have secure
| boot issues on those?
|
| The only reason there isn't a thriving community of third
| party OS's on most smartphones is because secure boot
| prevents it. And no, users do not have the freedom and
| choice to disable it (except on a very few models where
| the manufacturer has graciously allowed users to use
| their own devices how they want).
| A4ET8a8uTh0_v2 wrote:
| << Which is exactly why users have the freedom and choice
| to just disable Secure Boot?
|
| I might be misremembering it, but initial plans for
| Secure Boot were less open. It was only the stink raised
| that resulted in it being an option.
|
| << How often are you trying to install custom drivers on
| a smartphone, console or car? Why would you have secure
| boot issues on those?
|
| Does it matter? Is it mine? If yes, then it should my
| concern. But that is the entire problem with trusted
| computing and recent trends in general. Corps become
| operators, users are downgraded to consumers.
| cesarb wrote:
| > I might be misremembering it, but initial plans for
| Secure Boot were less open. It was only the stink raised
| that resulted in it being an option.
|
| That, and fear of antitrust enforcement. The only reason
| we're still allowed to disable secure boot, or enroll our
| own keys, is that alternative PC operating systems
| already existed and were popular enough, that attempting
| to restrict PCs to only run Microsoft-approved operating
| systems would raise serious antitrust concerns.
|
| But we're still at a serious risk. Microsoft still has
| enough influence over PC manufacturers to dictate their
| hardware requirements, and it would only take them being
| less afraid of antitrust to require them to no longer
| allow an override. They are already making things harder
| with "Secured-core PCs" (https://download.lenovo.com/pccb
| bs/mobiles_pdf/Enable_Secure...).
| hdgvhicv wrote:
| " . But not only were they illegal, like debuggers--you
| could not install one if you had one, without knowing
| your computer's root password. And neither the FBI nor
| Microsoft Support would tell you that."
|
| That's what trusted boot is, as predicted in 1997. It
| will come eventually.
| account42 wrote:
| > Cert authorities, just like in case of SSL. Is SSL also
| an evil technology designed to take away freedom from the
| internet?
|
| Yes, the way trust is delegated in web PKI is absolutely
| insane as well. It should have been something more lilke
| DANE from the start.
| preisschild wrote:
| > Who controls the fucking certs?
|
| You can? Delete the default (ie Windows certs) and import
| your own.
| m4rtink wrote:
| I think it is only required on x86 EFI machines due to
| some old antitrust rulings. Provided the firmware vendor
| actually implements it right.
|
| On ARM for example the hardware, including some hardware
| shipping with ARM version of Windows, does not need to
| provide the option to add custom certs and remove
| existing ones, so AFAIK in most cases it is not possible.
| gsich wrote:
| I do.
| h4ck_th3_pl4n3t wrote:
| Lol you never read about all the Lenovo malware fuckups,
| apparently.
|
| Which basically are exactly what "infosec fucktards" as
| you named them warned about.
| fsflover wrote:
| Consider using Heads with TPM and Librem Key to detect
| possible compromise of your boot stage. It doesn't obey
| MS but you.
| flexagoon wrote:
| With Heads, the firmware measures _itself_ and sends the
| results to the TPM. If an attacker flashes a modified
| firmware that simply lies about the measurement results,
| the entire security system will be bypassed.
| fsflover wrote:
| This is not true:
|
| https://forum.qubes-os.org/t/discussion-on-
| purism/2627/187
|
| https://forum.qubes-os.org/t/discussion-on-
| purism/2627/177
| froh wrote:
| that's still secure boot, isn't it? just not uefi but
| homegrown?
|
| fine with me. I read GP as rejecting the whole idea.
|
| to point at another elephant in the room: at some point I
| came to realize that the ME is a x468 running some BSD.
| that little bitch has full access to your machine.
|
| if trust and security is the objective, we're in for a
| hard ride to find trustworthy hardware.
| zozbot234 wrote:
| > I'd love to know if my machine has been compromised
| with early boot stage "meta-hypervisor" or not.
|
| Boot from read-only media you control, or set up network
| boot from a source you trust - you have to trust the
| firmware anyway. Secure Boot itself is quite pointless.
| FuriouslyAdrift wrote:
| Now do Systemd...
| drowsspa wrote:
| Yeah, it opened up the door for us not owning not even our
| phones anymore, and soon even the browser itself.
| deknos wrote:
| orrr we just have official institutions which do this and
| enforce vendors to add certificates from other trusted
| parties. not only microsoft is able to do this. also
| microsoft already also had fallout regarding signing.
|
| and secure boot is still the antichrist, but we have to live
| with them.
| danudey wrote:
| The problem here isn't that Microsoft is the one signing
| the shim, but that we can't trust systems manufacturers to
| update their systems, or even to have systems that can be
| correctly updated.
|
| A public signing institution (or at least, a not-for-profit
| one) would be a great idea, but it wouldn't solve the core
| issue that we're worried about.
| WhyNotHugo wrote:
| Call me childish, but I don't want to ask Microsoft to sign a
| certificate for me before I install software onto my own
| hardware.
|
| I don't care if it's required for every installation of if
| it's once per hardware. I want to install software without
| asking a third party for permission. I want this to be doable
| entirely offline.
|
| Plus, keeping Microsoft's CA installed greatest reduces any
| security which I'd get from SecureBoot.
| preisschild wrote:
| > Plus, keeping Microsoft's CA installed greatest reduces
| any security which I'd get from SecureBoot.
|
| Can't you just remove all CAs from the UEFI and import only
| your own anyways with most mainboard vendors?
| xyse53 wrote:
| Yeah that's how my systems are set up. I also appreciate
| that each firmware let's me restore the original keys
| just in case without me having to manually back them up
| -- but they're not active for secure boot.
| trelane wrote:
| If Linux users had "stepped up to the plate" and demanded
| their own separate PKI, nothing would be different, except
| that every system that shipped with Windows would be locked
| to Windows. Dual booting would not be a thing.
|
| I mean, your statement is self contradictory. Linux users
| demanded no signing etc. So, had the industry listened to
| Linux users, there would be no signing. We do not live in
| that universe.
|
| There are some vendors that don't have secureboot. They are
| e.g. System76. You can enable your own SecureBoot if you
| want[1], though some things may not work, like checking GPU
| firmware signatures, because they are signed by Microsoft
| only (there are other issues, depending on how deeply
| Microsoft is assumed in your system, see e.g "On some
| devices, removing either of these keys could disable all
| video output.")
|
| [1] https://wiki.gentoo.org/wiki/Secure_Boot
| sugarpimpdorsey wrote:
| This makes no sense.
|
| Microsoft uses separate CAs (read: separate root
| certificates) to sign Windows vs Linux bootloaders.
|
| Both CAs have to be trusted. They could also, in theory, be
| revoked separately.
|
| There is no reason the "third party" CA couldn't be run by
| Red Hat. It's done by MS out of convenience.
| ChocolateGod wrote:
| But you can turn it off or en-roll your own keys.
| EnPissant wrote:
| It's just a default. You can override it with your own platform
| key.
| craftkiller wrote:
| You don't. I remove microsoft's keys from all of my systems and
| enroll my own key.
| saidinesh5 wrote:
| Just out of curiosity, how good is the secure boot experience
| these days?
|
| I've had to disable it on all my installations because of either
| nvidia drivers or virtual box modules. In general Arch based
| distros didn't seem too friendly for secure boot set up.
| bravetraveler wrote:
| Signature maintenance for modules can be fully automated.
| Enrollment requires navigating a mildly-intimidating interface
| a single time to accept the new PKI.
|
| Fine for systems you physically manage, anything remote in a
| datacenter I wouldn't bother _(without external motivation)_
| mormegil wrote:
| Which is strange because secure boot should be useful in
| _exactly_ the situation you don't have physical control of
| the HW, shouldn't it? I guess the threat model for a common
| not-that-important company does not include evil data center
| (and it's dubious if SecureBoot would protect you in
| reality), but wasn't that one of the motivations?
| bravetraveler wrote:
| Aye, though an evil maid has higher barriers and more
| paperwork in a DC.
|
| I hesitate based on that mitigation and the untold
| operational pain. Sometimes it's worth it, other times it
| isn't.
| ChocolateGod wrote:
| Well you can tie it to TPM to store your encryption key
| which should only produce the key when the boot parameters
| match the key. This is what Windows already does but its
| not fully supported under Linux and somewhat insecure as
| you can't encrypt the initramfs (so someone can infect boot
| process there instead).
| the8472 wrote:
| With a UKI the initramfs gets signed too, doesn't it?
| vbezhenar wrote:
| There are ways to solve that issue. But I think that
| you're correct, pinpointing the core issue with popular
| Linux distributions. It doesn't have to be this way,
| though.
|
| 1. You can sign and verify initramfs, it's supported by
| bootloaders.
|
| 2. You can merge kernel and initramfs into UKI and sign
| the whole image.
|
| I don't know why that's not implemented.
| michaelt wrote:
| _> Which is strange because secure boot should be useful in
| _exactly_ the situation you don 't have physical control of
| the HW, shouldn't it?_
|
| One of the ways you can introduce your own signing key is
| as a Machine Owner Key, using the "MOK Manager"
|
| But a design goal of this software was: We don't want
| malware with root to be able to introduce a MOK without the
| user's consent, as then the malware could sign itself. So
| "MOK Manager" was deliberately designed to require
| keyboard-and-mouse interaction, early in boot before the
| network has been brought up.
|
| Of course if your server has a KVM attached, you can still
| do this remotely, I guess.
| paulv wrote:
| My experience as a long time Linux user (since 1997, so
| admittedly stuck with some bad habits from when things were
| actually hard to get working) has been that things are kind of
| confusing if you deviate from the golden path, but if you are
| on the golden path you won't ever notice that it is turned on.
|
| The laptops I have gotten from eg Dell with Linux pre installed
| have just worked. Machines I have upgraded through many
| versions of Ubuntu (lts versions of 16-24) were weirdly broken
| for a while when I first turned secure boot on while I figured
| it out, but that seemed reasonable for such a pathological
| case. Machines I have installed Debian on in the last few years
| have been fine, except for some problems when I was booting
| from a software raid array, but that is because I was using 2
| identical drives and I kept getting them confused in the UEFI
| boot configuration.
|
| I have not used them on machines with nvidia, vbox, or other
| out-of kernel-tree modules though.
| pbhjpbhj wrote:
| Every couple of years MS do an update that messes up multi-
| boot/dual boot. I'm sure it's on purpose at this point, and
| relatively sure "Secure Boot" is how they achieve it.
|
| Still on Windows only for kids games. Linux user since last
| millennium.
| blkhawk wrote:
| As a Linux-only gamer since 2019 I wonder what kids games you
| are talking about?
| repstosb wrote:
| There are things like Roblox that are really only usable
| under Windows due to a perverse idea of what "anti-cheat"
| should look like.
| blkhawk wrote:
| ah, I almost mentioned roblox but checking protondb it
| has gold status. So it should work?
| 71bw wrote:
| https://sober.vinegarhq.org/
| pbhjpbhj wrote:
| I can confirm Sober works really well, possibly slightly
| smoother than the Windows client.
|
| I couldn't get it to run via Proton/Wine at all.
| pbhjpbhj wrote:
| I've stopped trying to fight to install things on Linux.
| Anything with kernel level anticheat it seems is torment.
| They okay Fortnite, and quite a bit of Marvel Rivals (which
| initially worked, then stopped, I see reports suggesting
| it's working again but I don't have time to be full-time
| support to keep things running smoothly).
|
| We do use Kubuntu for games that run in it without drama -
| Risk of Rain, Roblox (via Sober), browser games, CS2.
|
| They also are expected to use Microsoft Office for school
| (UK), it's possible to work that online, but the experience
| is worse, slower, more prone to issues it seems.
|
| Fwiw, I've been a Linux distro user for decades and was
| Linux only until the first child got to highschool.
| Microsoft's "educational" policy works for them!
| ChocolateGod wrote:
| > Every couple of years MS do an update that messes up multi-
| boot/dual boot
|
| IIRC the last time this happened it was the fault of Linux
| distros not updating their packages, it was just a Microsoft
| update updating the security requirements that affected
| distros that were caught slacking.
| account42 wrote:
| The idea that MS should be able make orders that distros
| then have to follow is insane. If MS breaks something it
| absolutely is their fault.
| noAnswer wrote:
| So Windows installs something that brakes Linux boot. How
| are you supposed to boot Linux to install a fix? Am I
| expected to reboot into a different OS twice a day and
| check for updates? Am I slacking for not doing so?!
| chaz6 wrote:
| I use Fedora and have it enabled. Every time there is a kernel
| update I have to run a script to re-compile and sign the vmware
| drivers. I could probably figure out how to do it with dkms at
| some point. Every now and then, there's a kernel change big
| enough to make the vmware drivers stop working so I have to get
| a new patch.
| michaelt wrote:
| I would rate the experience as 6.5/10
|
| If you use a major distro like Ubuntu, you _might_ find Secure
| Boot works out-of-the-box, with no need to dick about with
| 'machine owner keys' and suchlike.
|
| Ubuntu has packages like "linux-modules-nvidia-550-generic"
| containing a version of nvidia's 550 drivers signed with
| canonical's keys. If the stars align and that package gets
| installed, you'll have nvidia drivers that work under secure
| boot.
|
| They also have a _second_ mechanism. You can set up a 'machine
| owner key' (MOK) then software updates will trigger
| automatically building new nvidia kernel modules, using 'dkms'
| then sign them with the MOK allowing them to work under secure
| boot.
|
| The problem is this process can be a bit wonky. The MOK setup
| process involves rebooting and going through the "MOK Manager",
| an interface that looks like something from the 1980s. If you
| didn't know to expect it, or what it's there for, or you don't
| speak English, it's easy to hit the wrong thing and not set up
| your MOK. And it only shows up for a single boot, unless you
| know an arcane terminal command.
|
| And if you run into any problems during the setup process -
| you're going to be researching the fix on your phone, because
| your PC isn't booting.
|
| Meanwhile, the _third_ option of just turning off secure boot
| is easy (assuming you know what the BIOS is) and it works every
| time. So a lot of 'how to set up nvidia drivers' guides just
| recommend doing that.
|
| Although I complain about it, I find it impressive things like
| dynamically compiling and signing kernel modules works as well
| as it does - especially as so much of it is maintained by
| volunteers, selflessly giving up their free time when they
| could have simply turned off secure boot in their BIOS too.
| icar wrote:
| With Arch, I've been using SecureBoot since sbctl [0] was
| released with 0 issues. Granted, I don't use any Nvidia
| hardware.
|
| [0] https://github.com/Foxboron/sbctl
| EnPissant wrote:
| UKI + secure boot works really well, but it is somewhat manual
| of a set up on Arch (what isnt).
|
| If properly set up the only files you generate are:
|
| - /efi/loader/random-seed
|
| - /efi/EFI/Linux/arch-linux.efi
|
| - /efi/EFI/Linux/arch-linux-fallback.efi
|
| and the .efi are all automatically signed by hooks.
|
| You can even skip a bootloader and boot the images directly.
| IHawkMike wrote:
| I just finished setting this up and it's definitely this
| easy. The hardest part was growing the ESP to dual boot with
| Windows but that is basically just copy/paste the files to a
| bigger partition and change the partition type GUIDs.
|
| Most of the guides focus on creating the PK, KEK, and db
| certs for enrolling/updating certs from userspace with signed
| .auth files but that is kind of pointless and seriously over-
| complicates it. I just created a 20-year db key pair with
| openssl (and PK and KEK just to make sbctl happy due to a
| bug), then installed the public db cert into the UEFI
| manually via the ESP. Didn't even need to use setup mode,
| although I suspended BitLocker on the Windows partition to
| let it reseal its key with the new PCR 7 measurement after
| the db update.
|
| To finish securing it I have a separate key for PK and KEK
| and have already installed Microsoft's 2023 UEFI certs in the
| db (and added the 2011 cert to dbx with the updated bootmgr).
| EnPissant wrote:
| I just used sbctl to generate and install a platform key in
| setup mode. It worked well.
| CoolCold wrote:
| just doublechecked with "Confirm-SecureBootUEFI" - says True on
| my laptop which used > 1 year. I'm pretty sure on the previous
| system which was used for 4 years it was on too - have not
| noticed any issues.
|
| Windows 10 and then 11
| jeroenhd wrote:
| It works pretty well out of the box unless you're trying to
| combine Linux with Nvidia hardware. Even with Nvidia hardware
| it doesn't take that much effort to make it work, but as usual,
| Nvidia requires taking extra steps.
|
| What Linux is really lacking is a user-friendly method for
| enrolling your own keys, which would instantly solve all the
| Nvidia/firmware updater/custom bootloader problems. The command
| line tools are slowly getting easier to use, but there's no
| guided instruction flow.
| vbezhenar wrote:
| I'm using Arch and it was very easy to configure secure boot. I
| don't know why you think it's not friendly. I'm using UKI, so
| no bootloader at all, my UKI is signed by my own key which is
| installed into UEFI. Most of sign process is handled by
| systemd, so most of it is already integrated into the base
| system.
| Avamander wrote:
| One checkbox during install when using Ubuntu with custom DKMS
| modules. That's it. For the past five or more years.
| roschdal wrote:
| Secure boot is so evil.
| eqvinox wrote:
| No it's not. Secure boot without user control is evil. UEFI
| generally allows user control. Of course a vendor can make an
| UEFI system that doesn't allow user keys... don't buy that.
| negative_zero wrote:
| Well I can say that the update is not going 100% smoothly. I have
| a pending KEK update in Fedora but it's a test key (bug filed but
| no progress as of yet).
| mkj wrote:
| It's not just Linux - certificates to sign Windows are also
| affected in 2026.
|
| https://support.microsoft.com/en-us/topic/windows-secure-boo...
|
| https://techcommunity.microsoft.com/blog/windows-itpro-blog/...
|
| Really it seems like having any expiry date for these
| certificates is a mistake. The one thing it might protect against
| is a compromised signing key, but if you have to wait 15 years
| for a compromised key to stop being valid, it's not very useful!
|
| Don't worry, the replacement MS certs expire in 2038 (a couple of
| months after the 32-bit unix time rollover).
| littlestymaar wrote:
| Is that really a mistake? Or Microsoft just has no interest to
| care about computers not working as intended anymore.
|
| It certainly wouldn't be the first evidence of that...
| pjmlp wrote:
| Being cynic, there was the expectation that computers would
| get replaced before the certification expiration date.
| nirui wrote:
| I'm feeling/guessing the expiration is more of a flow-with-
| tradition thing. TLS certificates expires, it's part of the
| security feature, so why not Secure Boot certificates too?
|
| And of course, it gives the root certificate issuer enormous
| amount of power as well, good riddance from the POV of
| Microsoft.
|
| However, I think if Microsoft REALLY care about security, they
| should not let application installed on their system to do
| anything that is unapproved by the user (such as installing a
| virus that encrypts all their data), which could actually
| enhance the user experience and security. But, with secure
| boot, at least you can be sure that your Windows kernel is not
| tampered so it can serve the virus correctly :)
| jeroenhd wrote:
| The mistake was not to put an expiry date on the certificates,
| but to trust hardware vendors to do even basic firmware
| maintenance after motherboards and laptops leave the warehouse.
|
| In theory a KEK update will fix the expiry issue just like a CA
| package update on any normal operating system will do.
|
| In practice, most UEFI firmware is written like trash,
| unmaintained, and mostly untested.
| RedShift1 wrote:
| Which to me leads me to a bigger problem, UEFI is trash, too
| complicated, too bloated, too hard to implement all the
| various bits and pieces.
|
| In my opinion the system firmware should do the absolute
| minimum possible. Find a piece of data somewhere that the
| processor can start executing, like in the BIOS days where it
| would just load in the first 512 bytes and start running
| that. Anything else like hardware configuration, power
| management, etc... should be left to the operating system.
| tliltocatl wrote:
| That's not realistic. Too much stuff is board-dependent and
| trusting vendors to upstream it (or even disclose
| documentation) isn't going to work never ever. I think what
| should be done instead is to swap privilege levels so that
| after-boot firmware services runs under operating systems,
| not above it. ACPI, with all it's sins, is pretty close. On
| the other hand, RISC-V made same old mistake of introducing
| SMM under other name into their supervisor spec and addeed
| their own secret sauce of forcing damn TIMER interface to
| go via SBI (seriously, WHY? High timer latency was known to
| be a problem om x86s requiring all sorts of weird tricks
| since Win95 or so).
| hypercube33 wrote:
| EFI was part of the itanium culture at Intel to reinvent
| the IBM PC. I think it's one of the few surviving legacies
| of all of that.
| m4rtink wrote:
| Mobile phones and a lot of embedded systems have minimal
| system firmware like this and it is a total disaster,
| basically forcing you to have per device special software
| releases with all the hardware specific things EFI would
| abstract for you, enabling a generic system software image
| supporting many devices.
|
| As a result, many of these devices are buggy, insecure &
| are never updated once shipped or updates get abandoned
| soon after.
| msgodel wrote:
| You do also need to assist the OS in doing hardware
| probing. Even older BIOS systems had ACPI and other
| standards.
| jeroenhd wrote:
| UEFI standardizes the things vendors and operating system
| manufacturers were already doing anyway. Even in the BIOS
| days, firmware was doing PXE boot and things like modifying
| Windows' memory to inject a binary at boot time to inject
| their drivers/crapware into clean installs.
|
| You can flash all kinds of alternative firmwares to many
| motherboards if you know where to look, but those firmwares
| often end up reimplementing everything UEFI does to get an
| operating system to work in the first place. Some firmware
| distributions even use a full Linux kernel as a UEFI
| replacement.
|
| I'll take UEFI over BIOS any time if only because it
| finally solved dual booting.
| xg15 wrote:
| > _modifying Windows ' memory to inject a binary at boot
| time to inject their drivers/crapware into clean
| installs._
|
| Wait, what? Did this thing at least have the courtesy to
| check that you were indeed booting Windows or would you
| just get random crashes if you tried to use the
| mainboard(!) with any other OS?
|
| This stuff seems inches away from a supply chain attack.
| OptionOfT wrote:
| https://view.officeapps.live.com/op/view.aspx?src=https%3
| A%2...
|
| It's more that Microsoft would read & execute a binary
| from a specific place in memory, allowing companies to
| maintain persistence / ensure their drivers are always
| installed / ...
| DSMan195276 wrote:
| The real myth here is that the BIOS did nothing more than
| load 512 bytes and start executing. It was already doing
| tons of stuff to configure hardware and provide information
| to OSs well before UEFI came along.
| RiverCrochet wrote:
| All the "PnP"/"ESCD" stuff the pre-UEFI BIOS did was to
| support DOS or because of DOS. APM leveraged SMI for fan
| and power control so DOS would work on 90's era laptops.
| That whole mess morphed into the nightmare of ACPI and
| UEFI.
|
| The only thing a firmware really needs to is A)
| initialize RAM, B) initialize a display or serial port
| for boot comms, and C) load an OS. Anything else modern
| firmware does would be better as normal devices
| controlled by OS drivers without the ACPI/UEFI layer.
|
| A third thing: it is of course super convenient if
| firmware provides some way to reliably identify the
| platform and provide data on devices that aren't
| connected to discoverable buses (such as bus controllers
| themselves), but even that's not really required. Linux
| lets you build a devicetree as part of the kernel.
| account42 wrote:
| No, the real mistake was putting the root of trust anywhere
| else than the user.
| jeroenhd wrote:
| The user can load their own keys into their secure boot
| storage and use those keys without any interference from
| pre-installed certificate authorities.
|
| This issue only affects the people who don't want to bother
| being the root of trust.
| kragen wrote:
| From Microsoft's point of view, that's not a mistake. It's
| the whole point! The user is a potential pirate, after all.
| numpad0 wrote:
| There is no basic firmware maintenance to do. Firmware is
| supposed to be properly engineered, immutable, still to this
| day sometimes physically wired as 1s and 0s. It doesn't make
| sense to have expiry dates carved in stone.
| jeroenhd wrote:
| Firmware needs maintenance because unless you're doing
| stuff for the aerospace industry, you're not mathematically
| proving that your firmware is bug-free. Eventually someone
| will need to install updates.
|
| Well-written firmware doesn't need to be updated for the
| key database to get updated. However, some vendors messed
| up and now require firmware updates, while others simply
| store the new key in NVRAM.
| danudey wrote:
| Not to mention that firmware updates are often necessary
| for things like supporting new CPUs. Immutable firmware
| means that your system can never improve or expand to
| support new hardware, and I would hate to have to buy a
| new motherboard to support a new CPU.
| numpad0 wrote:
| You shouldn't need new improved proprietary software to
| support new hardware, that's just wrong. They're just
| bundling free apps into hardware at that point.
|
| "New CPU needs a new software" shouldn't be an excuse to
| just let CPUs becoming its own computer with the real CPU
| you're paying for as one of many features. That's just
| fundamentally wrong.
| josephg wrote:
| That is reality though. It happens all the time.
|
| Modern computers are distributed systems of components.
| Each component has its own cpu and OS running in
| firmware. And they talk over the system bus.
| rolph wrote:
| it seems like you are talking about hardware controllers,
| vs CPUs.
| mkj wrote:
| What purpose does the expiry date have? There might be
| something I've missed, but I really can't see one apart from
| needless complication, which is what makes it a mistake.
| (There are other problems in the UEFI/firmware ecosystem yes,
| but that doesn't excuse expiry dates)
| jeroenhd wrote:
| I don't know if this is why the people behind secure boot
| adopted this design, but expiry dates make CRLs smaller, at
| least in theory. If a revoked certificate expires, you
| don't need to add it to the CRL because trust is
| invalidated automatically. By rotating root keys
| occasionally, you can also keep the revocation list for
| vulnerable bootloaders smaller, as you can remove any
| vulnerable bootloader when its signatory key expires.
|
| With the kind of penny-pinching that happens with NVRAM
| storage on boards like these, being able to reduce the size
| of CRLs can make a difference.
| mkj wrote:
| Hm, I guess that's one point. 15 years worth of
| accumulated revoked certs is a pretty big list though,
| not sure how much they win there.
|
| Idle thought - wonder if there are perfect hash-like
| constructions they could use for revoked certificate
| lists.
| roryirvine wrote:
| UEFI's equivalent of the CRL is the "forbidden signature
| database" (or DBX) - but as far as I can see, it only has
| 658 entries (the source appears to be https://github.com/
| microsoft/secureboot_objects/blob/main/Pr... )
|
| Another potential use is to facilitate managed
| deprecation of obsolete crypto functions / protocols /
| hash suites / etc.
|
| That fits pretty well with a 10 year rotation period, and
| is probably more valuable in the long term than
| minimising DBX size.
| trelane wrote:
| As a Linux user, I am shocked-- _shocked!_ --to hear that
| consumer hardware vendors are taking shortcuts and abandoning
| maintenance as soon as they can.
| semi-extrinsic wrote:
| > Really it seems like having any expiry date for these
| certificates is a mistake.
|
| Especially when most relevant attacks occur in the scenario
| where attacker has control over the system clock.
| trebligdivad wrote:
| Disaster recovery planning must be fun - 'take a fresh machine
| from store A, and use the Windows CDs stored in box B, and....'
| Artoooooor wrote:
| Just another factor creating electro-junk. Currently I can
| install 30 year old system on 30 year old hardware (assuming that
| I keep both the machine and the installation media in a good
| shape). With current computers it will be impossible because they
| will be "unsupported".
| jeroenhd wrote:
| Just disable secure boot if you can't update the certificate.
| You can still use your computer.
| omnibrain wrote:
| I'm sure this is a naive take, but why is it not possible to
| enter a new key into the BIOS (dating myself, I know it's EFI) by
| hand?
| nottorp wrote:
| You'd have control over what boots on your computer then...
| nicman23 wrote:
| you literally have though. you can self sign everything and
| set up uefi to only boot your signature
| const_cast wrote:
| Only on x86 secure boot implementations. On most devices
| with trusted boot, you don't have this option.
| nicman23 wrote:
| uefi on non x86 is a non starter for most people anyways.
| not that uboot is better
| ozgrakkurt wrote:
| That would be a disaster. Or imagine what would happen if you
| just disabled secure boot, your computer will be infected
| with viruses and your bank account emptied instantly I reckon
| Dead_Lemon wrote:
| Secure boot doesn't stop user-space malicious activity.
|
| I'd argue that it only helps check a tick box on corporate
| security manifest, as it indicates the kernel being booted,
| is not tampered with.
| OldfieldFund wrote:
| OP was being sarcastic
| nicman23 wrote:
| it is
| jcgl wrote:
| It should be, at least on higher-end boards, no?
| eqvinox wrote:
| It's possible and it's what you should be doing. "sbctl"
| (https://github.com/Foxboron/sbctl) AFAIK has a reasonable
| frontend for doing that on Linux (don't know, I did it
| manually). You have to put the system in "secure boot setup
| mode" in BIOS/UEFI options before booting, which enables
| changing the PK (Platform Key) which is used to chain off all
| the other keys. (Setup mode should be automatically exited when
| you install a new PK.)
|
| You can keep the Microsoft keys in there if you want to dual
| boot Windows, you just need to re-sign the keys themselves with
| your own PK.
| xiconfjs wrote:
| Is there a reliable command in Ubutu to check for the secure boot
| key and its expiration date?
| porridgeraisin wrote:
| mokutil
|
| Check its various options
|
| The 'Validity' field in the output will tell you the expiration
| date.
| eqvinox wrote:
| mokutil is technically the wrong tool for this, it lists
| shim-installed machine owner keys (MOK). This is about UEFI-
| installed key exchange keys (KEK). If you don't know what's
| going on you'll be very confused about empty key lists. It
| can in fact show KEKs but you need to know that this is a KEK
| thing to begin with... mokutil --kek | egrep
| '(Not |Subject:|^[^ ])'
|
| is the magic incantation if you really want to use mokutil
| porridgeraisin wrote:
| Secure boot, disk encryption, etc are more trouble than they are
| worth IME. I have them all off.
|
| Qualifier: for personal computers that you don't take regular
| backups of, test backups, etc
| flexagoon wrote:
| Secure Boot's benefits are definitely not as strong (I don't
| think flashing custom backdoored firmware is a common attack
| vector for personal computers), but FDE is still useful in case
| your laptop gets stolen, because thieves looking for sensitive
| data on a hard drive is a thing that does actually happen.
|
| I also wouldn't really say it's much trouble. If you have a TPM
| and use systemd, you can set it up to unlock FDE automatically
| on boot, otherwise, you just have to input an extra password
| when turning on your machine.
| zozbot234 wrote:
| SB does not protect against backdoored firmware at all. You
| would need something like BootGuard which is a separate
| feature.
| palata wrote:
| Can you elaborate on that? Isn't it the whole point of
| secure boot?
|
| My understanding is that at least on Android you can't
| modify the system: you have to format everything if you
| want to make a change at this level.
| Avamander wrote:
| No, SB starts with actually firmware already booting
| something. It is just one link in the chain. You can also
| look up Trusted Boot and Secure Launch, how this entire
| chain can/could be secured.
| palata wrote:
| > SB starts with actually firmware already booting
| something.
|
| I don't understand that sentence. So instead of a
| bootloader in the ROM that starts the next bootloader and
| verifies that it is signed (I think that's how it is on
| Android?), on a laptop the first bootloader can be
| installed by the user and nothing checks its signature?
|
| EDIT: what I read here [1] is that Secure Boot is
| verified from the ROM to the moment it starts "the
| Windows kernel" (on Windows). But it's not completely
| clear to me: say on Linux, if Secure Boot verifies up to
| my /boot partition (does it?), then it should be okay
| because I have FDE on the rest, right?
|
| [1]: https://learn.microsoft.com/en-
| us/windows/security/operating...
| chabad360 wrote:
| It should be noted, it is 100% possible to use Secure Boot with
| Linux and not be impacted at all. AFAIK, most (if not all) UEFI
| firmwares allow enrolling your own keys. Managing secure boot
| these days is as easy as installing sbctl and adding a hook to
| sign your kernel when rebuilding the initramfs. For the same
| price, as noted by the article, the key new key can be updated
| while the system is online without anyone being the wiser.
|
| The FUD that gets spread around SB helps no one, and other than a
| small list of exceptions, you are always in control of your
| system.
|
| SB allows MS to transparently enable Full Disk Encryption by
| default, which I think is a win for all users. It allows you to
| do the same on Linux. It lets server operators be sure their
| systems have not been tampered with. While there are many
| problems with UEFI, SB is not one of them.
| TacticalCoder wrote:
| > Any installed distribution should have a bootloader signed with
| its own key that will continue to boot
|
| I'm kinda concerned here: as long as there's no mandatory
| security upgrade requiring a reboot, I'm the kind of person to
| reach six months of uptime with my desktop (yup, Linux is that
| stable, a far cry from Windows).
|
| So I'm concerned about not being about to boot in _x_ months and
| forgetting why (ah, yes, Microsoft having a key expiring).
|
| Am I correct in my understanding that this only affects my
| installation media and not my already installed systems?
|
| Lastest Debian stable FWIW.
|
| Oh well, I take it it's going to be _mokutil_ and whatnots when I
| get back home.
| palata wrote:
| [Warning: I'm not interested in sarcasm or uninformed rants
| against secure boot, there are plenty already]
|
| I'm hoping to get insights from people who understand secure boot
| well here. My understanding on Android (for the minority of
| Android manufacturers that do it correctly) is that there is a
| "manufacturer key" burnt somewhere on the ROM that cannot ever be
| changed, and once a first system is installed properly:
|
| 1. It is impossible to overwrite the system partitions unless the
| bootloader is unlocked from the already-installed OS (I assume
| that something makes sure that only the signed OS can unlock the
| bootloader?).
|
| 2. Once the bootloader is unlocked, it is impossible to overwrite
| only parts of the system: it's all or nothing, such that one
| cannot inject stuff into an existing system (evil maid style).
|
| Still on Android, it's possible to add custom keys. That's what
| GrapheneOS and the likes use.
|
| How is it on UEFI? It sounds like the "manufacturer keys" are
| always from Microsoft, but is there not a way to use custom keys?
| jeroenhd wrote:
| > Still on Android, it's possible to add custom keys. That's
| what GrapheneOS and the likes use.
|
| AFAIK, that depends on the hardware used. Google Pixels allow
| it, but it's not universally permitted. Plenty of stories can
| be found on XDA where people tried to lock their bootloader
| that bricked their phone.
| palata wrote:
| > AFAIK, that depends on the hardware used. Google Pixels
| allow it, but it's not universally permitted.
|
| You're right! That's what I mentioned the few manufacturers
| who do it correctly. GrapheneOS only supports Pixels for
| other reasons than that. CalyxOS supports other devices (one
| constraint being to be able to relock the bootloader). /e/OS
| doesn't seem care so much about the secure boot.
|
| > Plenty of stories can be found on XDA where people tried to
| lock their bootloader that bricked their phone.
|
| That raises a question: what is the point of relocking the
| bootloader? If overwriting the keys means that the whole
| system will be formatted, then I don't see why it should ever
| be prevented at all? If an evil maid wants me to lose my
| data, they can leave with the laptop, right?
| vbezhenar wrote:
| Of course it is possible to use custom keys. At least it was
| possible on all EFI computers I owned. There are no
| "manufacturer keys". There's usually an option in BIOS to
| restore default configuration which resets to MS keys, but you
| can delete all MS keys.
|
| Now there might be further complications, for example some
| Lenovo laptops using firmware blobs signed by MS keys and if
| you delete MS keys, you might brick your laptop, because GPU
| won't start anymore. That said, I'm using Lenovo Thinkpad T14s
| Gen4 Intel right now with all keys deleted and my custom key
| added and it works just fine. May be it's AMD issue.
| palata wrote:
| > Now there might be further complications, for example some
| Lenovo laptops using firmware blobs signed by MS keys
|
| Oh right! Yeah if you want to use custom keys, you need to be
| able to build and sign your OS, and proprietary firmwares are
| then a problem. Now I wonder why this is not a problem on
| Android... Is it because the firmware blobs come from the
| image that you sign yourself?
|
| Would the solution be that the GPU should load the firmware
| from the OS?
| okanat wrote:
| You don't need to be able to build them. Just sign them or
| sign the keys that sign the third party blobs/binaries.
|
| Then your motherboard firmware will be able to load your
| GPU and other third party blobs to UEFI memory. Similarly
| OSes like Linux and Windows enforce the same chain of trust
| (they don't have to but otherwise it is not really secure,
| just like a website can lie to you about encrypted storage)
| so you need your drivers/OS loaded firmware to be signed as
| well.
|
| What Android does and what UEFI does are not really
| related. It is like comparing how SSH does authentication
| vs how HTTP with TLS does. Former is a SSH-specific open-
| ended implementation detail, latter is standardized by
| IETF.
|
| Similarly UEFI standardizes how a motherboard manufacturer
| can write a compatible firmware and Secure Boot (capital
| letters) is a sub specification of UEFI. It is not the only
| secure boot implementation scheme.
|
| With Android device manufacturers have complete control
| over the early boot firmware and the OS. As long as they
| boot the OS to run apps, how they do it is up to them. Only
| things like Google's SafetyNet will put certain
| requirements on them. No standard like UEFI exists in
| Android phone world or anywhere else except PCs / Servers.
| eqvinox wrote:
| > It sounds like the "manufacturer keys" are always from
| Microsoft,
|
| The primary key is called "Platform Key" (PK) on UEFI, there
| can be only one, and it is generated by the mainboard
| manufacturer, not Microsoft. The PK is then used to sign Key
| Exchange Keys (KEK) which you will generally have 2...4 of, the
| Microsoft self-use one, the Microsoft third party one, a board
| vendor one, and a system/board specific one.
| palata wrote:
| And next to those you can load your custom keys?
| eqvinox wrote:
| You need to replace the PK with one of your own, because
| that is used to sign all the other keys, and generally
| there can only be one PK. You can then re-sign the existing
| keys with your own PK (e.g. if you want to dual boot
| Windows) -- or just ditch the existing ones1, and/or you
| can generate your own keys of the other types (KEK & DB).
|
| Ed.: 1 there are cases where ditching the existing keys
| breaks the system, because the board vendor was stupid and
| signed the VGA UEFI driver with one of those keys instead
| of tying it directly into the BIOS/UEFI image. AFAIK this
| only affects a specific series of Lenovo laptops, but
| Google the details before breaking your system.
|
| Ed.#2: actually I think the PK signature is only checked
| while installing keys into the KEK/DB list, so you don't
| need to re-sign the existing Microsoft keys, they just stay
| in the list by default. (Unless they got cleared somehow.)
| It's been a little while since I did this.
| xyst wrote:
| Reading into the history of Secure Boot. Discovered Intel and AMD
| processors have back doors via Intel Management Engine [1] and
| AMD Platform Security Processor [2]. Both are closed source and
| have had a number of vulnerabilities over the years. They are
| essentially backdoors.
|
| Seems disabling these "features" is nearly impossible as well.
|
| [1] https://en.m.wikipedia.org/wiki/Intel_Management_Engine
|
| [2]
| https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces...
| jeroenhd wrote:
| I wonder what my laptop will do soon.
|
| Lenovo, in their infinite wisdom, has decided to load an Nvidia
| blob signed by Microsoft before even being able to access the
| UEFI firmware interface. People who have tried to install their
| own secure boot keys found out the hard way that you can't even
| get into the firmware configuration interface to undo the change.
|
| Their official workaround is to only load secure boot keys
| through their firmware interface (rather than the standard Linux
| utility) which refuses to wipe the certificate used to sign the
| Nvidia firmware. However, that workaround will obviously stop
| working when that certificate expires.
| craftkiller wrote:
| The Framework laptop with the AMD 7840U works perfectly without
| any microsoft keys enrolled.
|
| For your current laptop, you might be able to use the `--tpm-
| eventlog` to `sbctl enroll-keys` to enroll hashes of your
| OptionROM to whitelist that blob.
| eqvinox wrote:
| > Linux users who have Secure Boot enabled on their systems
| knowingly or unknowingly rely on a key from Microsoft that is set
| to expire in September.
|
| No I don't because I installed my own keys, and so should you,
| and can we please stop assuming that Secure Boot means Microsoft
| keys?
| laserbeam wrote:
| The article should include a very obvious way for someone to test
| if they are affected. How does one verify (in an in a VERY clear
| and straightforward way) if some arbitrary system will run into
| this issue in September?
| mkj wrote:
| Set your clock to December, reboot, and see what happens.
| iforgotpassword wrote:
| Fuck secure boot. A fun project, even if mostly for educational
| purposes, would be to collect all the different exploits that
| have been found over the past years and try to create a universal
| secure boot bypass loader that targets as many of those as
| possible. I guess chances are that if your vendor didn't update
| the firmware to include the newer ms keys, they also didn't patch
| any of the exploits. So we just need to also get this super
| exploit loader signed so that it works everywhere :o)
| horseradish8h wrote:
| could we just set the clock backwards on shutdown and forwards on
| boot? or do the keys delete themselves after the date?
| upofadown wrote:
| >Currently, shim is signed with a Microsoft key from 2011 that
| expires on September 11.
|
| What security benefit did adding an expiry date to the
| certificate provide? "Oh no! Someone has gotten our secret key
| and is certifying new shims! ... Not to worry, the certificate
| will expire in 14 years. Everything is fine!"
|
| Does anyone know the rationale for such expiry?
| Avamander wrote:
| Knowing that any quicker rollover would've hindered or even
| stopped uptake before the technology got established?
| pabs3 wrote:
| Luckily I only use hardware from dumpsters that is old enough to
| have BIOS boot mode.
| jmclnx wrote:
| And this is why I avoid and will always avoid "Secure Boot". I
| can see many newer Linux people being locked out starting in
| Sept.
| craftkiller wrote:
| Or you could just remove microsoft's keys from your systems and
| sign your bootloader with your own key. That's what I do on all
| of my systems so I am unimpacted by this.
| ekianjo wrote:
| do you have any source on how to do that?
| craftkiller wrote:
| I followed https://github.com/nix-
| community/lanzaboote/blob/master/docs... but naturally you
| don't want to include the `--microsoft` flag when running
| `sbctl enroll-keys` if you want to avoid microsoft keys.
| Also Lanzaboote is only for NixOS.
| marcthe12 wrote:
| The arch wiki has the best source https://wiki.archlinux.or
| g/title/Unified_Extensible_Firmware...
|
| Note sbctl is one of the easier tools to do this.
| josephcsible wrote:
| Sure, but that's a lot more work than just disabling Secure
| Boot, and for most people's threat models, there's zero
| actual security benefit gained in return.
| brudgers wrote:
| _Warning: Replacing the platform keys with your own can end
| up bricking hardware on some machines, including laptops,
| making it impossible to get into the firmware settings to
| rectify the situation. This is due to the fact that some
| device (e.g GPU) firmware (OpROMs), that get executed during
| boot, are signed using Microsoft 3rd Party UEFI CA
| certificate or vendor certificates. This is the case in many
| Lenovo Thinkpad X, P and T series laptops which uses the
| Lenovo CA certificate to sign UEFI applications and
| firmware._
|
| "Just" is doing a lot of heavy lifting in that solution.
|
| https://wiki.archlinux.org/title/Unified_Extensible_Firmware.
| ..
| willa_bombadier wrote:
| There should be some "Sane Usage" certification that a device
| doesn't do secure boot, provides fully open and self-
| maintainable hardware, is independent of all external entities
| for ongoing use, provides hardware switches to turn off built-
| ins like ports, mics, and cameras, for power-savings and
| security.
| pydry wrote:
| "Will this piss off or delight Microsoft?" is probably a
| thought that goes through the heads of many OEMs when they
| decide how to design their machines.
| msgodel wrote:
| Weirdly Microsoft has been one of the companies ensuring
| Linux remains bootable on PCs.
| bayindirh wrote:
| Bill Gates famously asked: "Can we create a standard or
| expand something like ACPI, so Linux becomes unbootable
| on PCs?"
|
| So, believing this is very, _very_ hard.
| pydry wrote:
| Microsoft has been trying to tread a fine line between
| exerting subtle pressure on OEMs to make Linux annoying
| to boot so it doesnt become more popular and not
| violating the terms of its antitrust agreement.
| bayindirh wrote:
| To be able to get Windows licenses and preload Windows on
| your system, put that little Windows sticker and sell your
| machine to the masses, you need a Windows Compatibility
| certificate, and that certificate needs you to have Secure
| Boot and enabled by default.
| salawat wrote:
| Sounds anti-competitive as fuck to me. Maybe we should, I
| don't know; do something about companies using contractual
| requirements to lock key industrial into one way of doing
| things in order to shut down such efforts?
| edoceo wrote:
| What is the something we can do?
| lexicality wrote:
| Newer Linux people will presumably be using the new key though?
| 1970-01-01 wrote:
| So in 2025,2026 the simplicity of BIOS still haunts us. I realize
| this time it is a one-off cert issue, but there have been so many
| other non-trivial paper cuts in secure boot and UEFI
| implementation that I can't help but see this upcoming fix as
| spinning a roulette wheel of fixed/failed/bricked.
| RecycledEle wrote:
| This is yet another why I do not encrypt.
| craftkiller wrote:
| Secure boot has nothing to do with encryption. It is verifying
| crytographic signatures. The bootloader is signed, not
| encrypted.
| vbezhenar wrote:
| There's some link between secure boot and encryption.
|
| If you don't do secure boot, you need to secure your boot
| chain in other ways, to prevent attacker from modifying your
| software to log entered passphrase.
|
| Secure boot allows to build a verifiable chain of software
| (UEFI -> Bootloader -> Kernel -> Initrd) which will protect
| against any modification, so you can be sure that your key
| presses are not being logged by the malicious software. That
| said, commonly used Linux distros have some problems
| protecting initrd, but that's issue of those distros.
|
| Another link is TPM. I set up my system in a way to keep
| encryption key in TPM and release it only when secure boot is
| enabled. This allows to decrypt root automatically, without
| entering passphrase and my configuration only allows to boot
| UKI kernel signed with my key. It trades security with
| convenience, of course (because now attacker, who stolen my
| computer, only has to break through gdm or perform other ways
| of attacks like extracting RAM sticks), but for me it's
| acceptable.
| ahoka wrote:
| I think it's primarily to avoid someone just putting your
| SSD into any other computer and access all files. Anything
| more is probably not a realistic threat to most people.
| sgjohnson wrote:
| Secure Boot does nothing whatsoever to prevent that. Disk
| Encryption has got nothing to do with Secure Boot.
| craftkiller wrote:
| That's like saying there is some link between putting locks
| on your doors and setting up booby traps because if you
| don't lock your doors then you need to set up booby traps
| to prevent a thief from stealing your stuff. They're both
| trying to mitigate the same threat, but there is no
| connection between the 40 pounds of explosives I have wired
| to my front door and an intricate metal cylinder that can
| only be manipulated by another piece of metal in a specific
| shape.
|
| Personally, I do both secure boot and encryption.
| bri3d wrote:
| No, it's like saying there is a link between putting
| locks on your door and making sure the lock can't be
| replaced with one that takes someone else's key, or worse
| one that copies the key that's put into it. The threat
| models directly overlap.
| craftkiller wrote:
| That's a good analogy to point out the weakness behind
| relying on encryption without secure boot but without
| going into the mechanism behind "making sure the lock
| can't be replaced" people might incorrectly think
| "they're both about setting up locks and therefore they
| are linked" whereas "making sure the lock can't be
| replaced" involves securing the environment that the lock
| is placed in, like "Make sure your hinges are not exposed
| so the door cannot be taken off its hinges from the
| outside and replaced with a seemingly identical door."
| em-bee wrote:
| for most people that is an irrelevant threat model. people
| can steal my laptop, but if they don't know my passport
| they can't access my data. end of story. they would have to
| break into my laptop without stealing it to install any
| kind of tool that can read the password. how/when is that
| going to happen ever without you knowing it? you would have
| to be working on highly sensitive, and sought after stuff
| for someone to try that.
| craftkiller wrote:
| Unless you're using a SED, your EFI system partition is
| unencrypted. It would be trivial to build a malicious
| copy of popular open source UEFI bootloaders (grub,
| refind, zfsbootmenu, etc), and a bootable USB stick that
| scans your EFI system partition, replacing your
| unencrypted bootloader with a malicious one. This attack
| could then be applied by relatively unskilled people in a
| couple minutes ("boot this flash drive, wait until the
| screen says "done", power it off"). I hope your laptop is
| never out of your possession for more than a couple of
| minutes! (For example, the TSA at the airport, geek squad
| or other repair centers, or classically an evil maid).
| asmor wrote:
| Secure boot doesn't encrypt, secure boot only signs.
| carlhjerpe wrote:
| But it's very much a part of boot verification to unlock a
| TPM with your encryption keys on it.
| craftkiller wrote:
| You're conflating secure boot with measured/verified boot.
| carlhjerpe wrote:
| They don't work in tandem? I enable secureboot with
| sbctl(securebootctl) and enroll keys in a TPM using the
| same tool as far as I can remember.
|
| Or is this just some technical detail that in practice is
| under the same tools and settings?
| jeroenhd wrote:
| By default, the secure boot status is part of the TPM
| registers that are used to unseal the encryption key for
| your drive. That's because if you disable secure boot, or
| reconfigure it with different keys, any bootloader could
| just replay measurements from a normal Linux system to
| the TPM and unlock your drive.
|
| If you want, you can pick a different set of registers to
| use. The Arch wiki has a bunch of them: https://wiki.arch
| linux.org/title/Trusted_Platform_Module#Acc...
|
| Calling systemd-cryptenroll with --tpm2-pcrs would allow
| you to manually pick a set of options. I believe
| Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific
| register rather than a spec-defined one), which is why
| firmware updates often make you re-enter your Bitlocker
| key. Some people choose to only record the secure boot
| state, relying on the firmware to validate its own
| updates and config, which means you don't need your
| recovery key after firmware updates as long as the secure
| boot state remains the same.
|
| Not taking secure boot state into account makes the
| entire setup rather easy to bypass, but you could do it
| to make your setup harder to break while still protecting
| against the "thief steals my SSD but not my laptop"
| scenario.
| craftkiller wrote:
| In addition to the great answer by jeroenhd, you also
| might have encrypted your secure boot signing keys with
| your TPM. This has the advantage that your signing keys
| can't be stolen so you know that your bootloader was
| signed on your specific physical machine. But this is not
| necessary, you can just store your signing keys on your
| SSD or anywhere/anyway you want.
| max-privatevoid wrote:
| Using "Secure Boot" with MS keys is not real Secure Boot. It's
| "Microsoft decides what you may boot". Enrolling your own keys
| should be the standard way of operating. shim is a joke.
| WhereIsTheTruth wrote:
| Every single time when this concern is being raise, people get
| called "conspiracy theorist" and get "flagged" or muted, aka
| censored
|
| Fast forward today, yall are getting fucked deep in the ass
|
| Fuck Microsoft
| londons_explore wrote:
| Things that might not get updates shouldn't use the current
| date/time when checking certificates. Instead, they should see if
| the certificate _would have_ been valid on the day the firmware
| was compiled (ie. behaviour will never change through the passage
| of time alone).
| AnotherGoodName wrote:
| Expired certificates should also at worst be a skippable
| warning. No one's relying on certificates expiring for
| security. If you did you might have to wait many years for the
| expiration of a stolen certificate - lol!
|
| It's absolutely a minor "hey btw the certificate expired, check
| for an update" yet various systems treat certificate expiration
| as an end of the world lock it down scenario.
| Tuna-Fish wrote:
| Oh it's skippable all right. Just pull the cmos battery and
| wait a few seconds before putting it back in.
| londons_explore wrote:
| There's gonna be a bunch of linux users who write a
| shutdown script to set the date back to 2015 then
| poweroff... And at startup, reset the date back to today
| using the internet.
|
| Sounds like a cleaner solution than any of the ones in the
| article too!
| Tuna-Fish wrote:
| That's risky, an unclean shutdown would require resetting
| the clock which is a bother.
|
| It's much more likely that someone will write a driver
| that adds an offset to the clock, keeping the hw date in
| a safe range.
| homebrewer wrote:
| You can simply avoid adjusting the hardware clock. The
| kernel clock is not tied to it and can be modified
| separately. chrony can do that, for example.
|
| https://wiki.archlinux.org/title/Chrony#Real-Time_Clock
| andrewmcwatters wrote:
| Infosec engineers hate this one trick!
| amluto wrote:
| That seems to almost completely defeat the purpose of
| expiration. One could do a bit better by requiring the signed
| object to be timestamped by some sort of secure timestamping
| service. But then one should seriously consider the threat
| model that Secure Boot with default certificates is intended to
| defend against.
| AnotherGoodName wrote:
| There is no purpose to the expiration in this particular
| case. If you have an expiry of say 24hours and constantly
| update that makes some sense - stolen certs get a very short
| time window.
|
| If however you have an expiry of multiple years you clearly
| have no reason to have an expiry date at all. You can't
| possibly justify a security benefit, imagine reassuring
| people with "the stolen certificate is only valid for a few
| years!"
|
| As in it was clearly a mistake to have an expiry date at all
| for this use case and the multi-year expiry date should have
| been a smell that tipped people off and made them ask "why do
| we have an expiry date at all for this?".
| Tuna-Fish wrote:
| Even more, the "current date" comes from an external source
| that anyone with access to get new images on the machine
| can probably also manipulate. Setting the hardware clock is
| a normal operation available to the kernel.
| londons_explore wrote:
| If there were no certificate expiry, I could break into
| your system by finding some bankrupt company last trading
| in 1980 and stealing their keys to mint my own certificate.
|
| With expiry dates, at least the pool of places you can
| break into to steal certificate signing keys isn't growing
| without bound.
| em-bee wrote:
| there is a difference between the expiration of signing
| keys, and the expiration of the signature signed with
| those keys. the signature for a contract, or a
| bootloader, should remain valid indefinitely, even if the
| person/key is no longer allowed to sign
| contracts/bootloaders after some point of time.
| josephg wrote:
| That sounds impossible to enforce. Key signing is done
| offline. If I have an expired signing key, what's
| stopping me setting my clock back a few years, creating a
| new signature and signing it?
|
| If the resulting key works indefinitely, the expiration
| date on my signing key is utterly meaningless.
| withinboredom wrote:
| And what stops people from just logging into the bios and
| changing the date or pulling the clock battery? The point
| we're all making here is, at least for this application,
| is that an expiration is pointless.
| CaliforniaKarl wrote:
| Trusted timestamp services.
| https://en.wikipedia.org/wiki/Trusted_timestamping
|
| Microsoft's Authenticode has been doing this for a long
| time, allowing a signature to be considered as valid long
| after the signing certificate expired.
|
| https://learn.microsoft.com/en-
| us/windows/win32/seccrypto/ti...
| amluto wrote:
| You can do almost as well by finding a piece of software
| with a code execution exploit early in boot that's signed
| by the bank.
|
| A different model would be to only allow a given EFI
| binary to be booted if it was _installed_ before the
| deadline, but that might well have a different set of
| complications.
| montroser wrote:
| And what is the purpose of expiration in this case?
| stefan_ wrote:
| The day infosec nerds get rid of their unhealthy obsession
| with expiration and realize that systems irrecoverably
| breaking on an arbitrary random instant or requiring a true
| source of time to work are REALLY FUCKING INCOMPATIBLE with
| the real world, they might actually get something done. Until
| then, please don't bother the rest of us trying to get work
| done (and having to cleanup the mess you made - what do you
| mean you can't just update it?!)
| jacquesm wrote:
| Can't you just disable the internet connection, set the BIOS
| clock to a date before the expiration date to boot from the
| secure installation media and then reset it to the proper time
| after the installation is complete?
| LocalH wrote:
| It irks me that Microsoft managed to shim their way into the
| Linux boot process like this. No key signed by Microsoft should
| ever come into play when booting Linux, on a moral basis.
| Maxious wrote:
| you dont have to use the shim, just follow this
| https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htm...
| ThrowawayR2 wrote:
| Libre operating systems are coded to run on machines that
| conform to Microsoft's hardware standards and conformance tests
| (Windows HLK) that define Windows compatible hardware. Linux is
| shimming its way into Windows' boot process, not the other way
| around, even on machines sold with Linux from the manufacturer.
|
| If you want to be clean on "a moral basis", whatever that
| means, the FSF would have to create their own hardware standard
| and persuade OEMs to adhere to it. Good luck.
| jacquesm wrote:
| This is only the case because we let it be the case.
| Microsoft should have had zero influence on this. Consumer
| protection laws have utterly failed us.
| LocalH wrote:
| TIL UEFI is apparently a "Windows boot process" /s
| Sophia95 wrote:
| TLDR Linux systems using Secure Boot rely on a Microsoft
| certificate (from 2011) that will expire on September 11, 2024.
| After that, new Linux installs using Secure Boot may fail to boot
| unless the system firmware includes Microsoft's newer 2023 key
| and updating the key often requires a firmware update from
| hardware vendors which doesn't always happen. It's crazy that
| many users are relying on an outdated Microsoft key unknowingly
| (I will be checking if I'm among them smh) Also great that people
| are bringing awareness to this
| porridgeraisin wrote:
| I always have
|
| Secure boot off Disk encryption off Tpm off mitigations=off in
| linux kernel cmdline
| cm2187 wrote:
| It's not just secure boot. Modern OS have certificates all over
| the place. These are ticking self-destruct time bombs in those
| machines that the manufacturers of hardware based on these OS may
| not necessarily realize. I am thinking ATM machines, voting
| machines, medical equipment, smart-fridges and other IOT,
| probably many cars, etc.
| jacquesm wrote:
| Oh, they realize it just fine. To them it is just another
| source of revenue. Planned obsolescence is going to wipe out
| our digital heritage at some point.
| hcfman wrote:
| You would think it would be illegal to sell compute resources
| into Europe without an artificial expiration date controlled by a
| US company.
| kragen wrote:
| I didn't realize that the Secure Boot certificates that allow us
| to boot Linux at Microsoft's pleasure are things that _expire_.
| So all Microsoft has to do to kill end-user Linux is... nothing.
|
| How the hell did we get ourselves into this situation? After
| Microsoft spent years secretly threatening people with lawsuits
| for running Samba and Linux VFAT, and describing open source as
| "cancer"?
___________________________________________________________________
(page generated 2025-07-19 23:00 UTC)