What is an SBAT and why does everyone suddenly care
mjg59.dreamwidth.org
mjg59.dreamwidth.org
"trustworthy" according to who? Remember that dystopia does not appear spontaneously, but steadily advances little-by-little.
What's the summary? Microsoft (understandably) didn't want it to be possible to attack Windows by using a vulnerable version of grub that could be tricked into executing arbitrary code and then introduce a bootkit into the Windows kernel during boot. Microsoft did this by pushing a Windows Update that updated the SBAT variable to indicate that known-vulnerable versions of grub shouldn't be allowed to boot on those systems.
Who is Microsoft to decide what others do on their machines? Should they have the right to police and censor software they have no control of? In the spirit of Linus Torvalds: Microsoft, fuck you!
We are seeing the scenario Stallman alluded to over 2 decades ago slowly become a reality. He wasn't alone either.
https://www.gnu.org/philosophy/right-to-read.en.html
https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
Things like TPM and "secure" boot were never envisioned for the interests of the user. The fact that it incidentally protects against 3rd party attacks just happened to be a good marketing point.
"Those who give up freedom for security deserve neither."
I think understandably, everyone is concerned because it felt like an affront by MS against Linux. But, I don't think that was their thought process at all.
Given Microsoft's history, it's hard to really be sure. It's been a quarter century since The Halloween Documents and Microsoft definitely gives the air of contributing to the open source ecosystem today, but giants like having a big moat to defend, and old habits die hard. And Microsoft definitely has a reputation, even if, technically, undeserved.
They have never, ever supported anything other than the Microsoft bootloader[s], and if you work around that for instance it's pretty trivial to blow up your data by hibernating Windows and booting into a different partition. Resuming hibernation loads the old MFT onto the modified partition and you pretty much lose everything.
Definitely to be avoided, along with a few other considerations.
But experienced multibooters can usually reboot so quick that they have not had any need for hibernation since forever. It's almost like a valid excuse to not fully reboot a sluggish machine, more so than an energy-saving success. But I don't blame them.
Not that hard the more history there is.
Keep in mind that the default since the beginning of Linux is for someone who wants their PC to be completely Linux, never had a need for anything originating from Microsoft whatsoever. Something in firmware would really be the worst and it was immediately obvious when UEFI & GPT were foisted, with Microsoft SecureBoot to boot, that something was rotten somewhere.
A bigger threat than Linux was actually Windows 7, but with this exact hindsight now it can be seen how the knife was much further twisted for Linux well beyond the effective lifetime of W7. This was not just collateral damage, and it keeps on giving as if booby-trapped or time-bombed.
Also remember that until Windows Vista, motherboards and business machines from all major manufacturers were always common where there was no way to alter the BIOS itself in any way without physical access. Like a jumper on the board internal to the PC. Sometimes special key combinations on laptops accepted only from its built-in keyboard.
With BIOS settings only accessible to non-local users occasionally on specialized enterprise models according to options if present.
When you wanted to upgrade your BIOS, or "re-flash" it due to something like power line corruption, you always booted to the floppy containing the desired firmware after enabling the delicate flashing operation manually. By the time Vista arrived it was often a bootable CDROM, or a USB stick formatted FAT32 with DOS to substitute for a floppy. Whichever way you did it you wrote the same binary file into the BIOS chip, then with further access completely disabled after that, never need to worry about malicious firmware whatsoever as long as you used a clean binary.
The only possible way for a rootkit to infect your machine was to reside on your HDD. Usually in some of the spaces outside your filesystem that were so commonly unused it could lurk there and persist in spite of re-formatting.
But no rootkit or preboot contamination could withstand a complete HDD zeroing, or replacement HDD if needed under emergency conditions.
Well one day Microsoft must not have wanted people to ever boot DOS again, so they developed a need to access every BIOS from within Windows NT6, and manufacturers conformed. It only bricked machines significantly for a few years while the DOS way continued to be flawless for a while there.
It's a slippery slope, this got much worse once they forced UEFI on consumers, and malware can now reside in the preboot environment itself, which can often also access the web if connected.
Plus the motherboards have much more space for this kind of thing.
With Windows Servers and general Macs well-established beforehand at using EFI to restrict booting to only the exact OS that it was shipped with.
And everything on that Microsoft webpage introducing the advent of UEFI & GPT as a complete advantage in many ways, looking suspicious and turning out to be completely false without even waiting for the 20/20 hindsight there is now. The whole thing!
The cloak has now been further removed from this "false sense of security" system but surely not everybody wants to say out loud how sparsely-clad the emperor has become as he struts as if to demand the full respect once deserved.
So there hasn't been a physical way or available setting to prevent malicious access to sensitive PC firmware for quite some time, and who's most likely to blame for it?
No Windows "update" has ever made sense to change anybody's BIOS or UEFI firmware without being absolutely stupid as shinola, not like there was any question before this either.
This is also beyond most user recovery if you get malware in your UEFI.
Zeroing a HDD or SSD won't help you now like it would with BIOS.
You just can't fix shinola.
Intent, being squishy and debatable matters far less than the outcome.
I can say that I never intended X, but in the end, X still happened. That it happened unintentionally assuages exactly no injury from X having happened.
Intent, being squishy and debatable matters far less than the outcome.
I can say that I never intended X, but in the end, X still happened. That it happened unintentionally assuages exactly no injury from X having happened. Intent, therefore can only be considered as at best, an aggravating factor on top of the outcome.
Signed code fixes this by requiring someone actually put their name to the code. If it's not someone I recognize, I don't boot. And yes, the NSA could theoretically compromise a signing key with a $5 wrench. But then they blow their cover. Signatures create a paper trail that makes plausible deniability vaporize.
Using Windows in its default form means Microsoft already has a full backdoor into your machine, authorised by none other than MS itself.
Which gives me another opportunity to quote from my favourite Usenix paper:
"In the real world, threat models are much simpler (see Figure 1). Basically, you’re either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@ virus-basket.biz.ru. If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, they’re going to hold a press conference and say “It wasn’t us” as they wear t-shirts that say “IT WAS DEFINITELY US,” and then they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them. "
Figure 1:
Threat: Ex-girlfriend/boyfriend breaking into your email account and publicly releasing your correspondence with the My Little Pony fan club
Solution: Strong passwords
Threat: Organized criminals breaking into your email account and sending spam using your identity
Solution: Strong passwords + common sense (don’t click on unsolicited herbal Viagra ads that result in keyloggers and sorrow)
Threat: The Mossad doing Mossad things with your email account
Solution: • Magical amulets? • Fake your own death, move into a submarine? • YOU’RE STILL GONNA BE MOSSAD’ED UPON
-- https://www.usenix.org/system/files/1401_08-12_mickens.pdf
Is that why it took 10 years to find Bin Laden, the most wanted man on Earth?
Get the feeling intel agencies aren't as omnipotent or competent as they want people to believe.
He was also trained and equipped by the CIA.
So, if you're willing to live in caves where they can't easily search for you after being trained and equipped by the best of the best, sure, you might live slightly longer.
Doesn't seem like a tenable circumstance to me though.
https://www.theguardian.com/world/2011/may/03/osama-bin-lade...
You know that lies spread online easier than facts. Why make the problem worse?
There's plenty of completely unknown actors who I'm sure are on their radar, along with modern serial killers who despite leaving physical evidence have still evaded capture.
I've had brief dealings with cyber side of policing from reporting incidents and a few friends in the services, they all seem incredibly capable but have questionable amount of resources to do the job (along with not getting private sector wages).
Some seem repeat this phrase like it's a done deal but their job ain't easy, there's a huge amount of bad people out there in the world and there's only so much focus an agency can have. Think a little bit of realism is needed when someone mindlessly repeats such things.
It is funny, true, and wise, though.
Did you hear about Snowden?
people give up their security too easily...
the same applies to the threat model absolute bullshit. the threat model makes people think inside the box, meaning, they already accepted, by thinking inside that box, that there are people/entities they can't defend against.
https://www.eff.org/deeplinks/2016/03/deep-dive-why-forcing-...
https://en.wikipedia.org/wiki/Apple%E2%80%93FBI_encryption_d...
What these technologies protect is market share, nothing more.
Targeted attacks against individuals or small groups from state actors are basically impossible to protect against. Widespread compromises of all operating systems at the boot level should be fought against.
I don't really think malice explains Grub being limited b/c of Microsoft's software at the boot level. There's conflicting objectives at play, and that will inevitably produce, well, conflicts.
If the NSA grabbed your laptop, you've already lost. For instance, they could replace all input and output devices (keyboard, mouse, screen, audio, etc) with ones that not only log everything you do, but also allow them to remotely control your machine as if they were physically present. They could then pretend the laptop was opened (by falsifying the hall effect sensor which detects the lid state), power it on (by forging a press of the power button), log into your account (by replaying the password they logged earlier), and do anything they wanted, as if they were you. They could even use the camera to detect when you looked away for a second while logged into the laptop, and quickly do some input, bypassing any extra validation (like fingerprints or a smartcard) logging into your user account might have required. No need to modify or even touch the boot chain and storage.
That would be an amazing rant had it only ended with "Sent from my iPhone".
Since the Blaster worm incident two decades ago, we're in a new era where security at scale becomes the forefront responsibility of the companies developing the product. That includes writing more secure code, having more verifications in place, adopting more secure technologies, but also, limiting user capabilities in order to avoid at scale security incidents.
This isn't about Microsoft. Some of these "forced" limitations are: UAC (User Access Control)/SUDO, Bitlocker/Full disk encryption, App sandboxing/On-demand permissions, Signed firmware and boot mechanisms, signed release binaries, Jailbreak-protections, Limitations on raw packet operations, auto-installed updates, forced security updates, closed source code, built-in anti-malware.
When you have a billion devices running around the world, you can't say "hey we'll let this arbitrary group of billion people do what they think is best for them", because you then end up with Blaster worm, and the whole Earth falls apart.
Think about the more recent CrowdStrike incident. That kind of deployment has been performed by professionals, not even regular people, and yet, it's managed to bring down the entire world to its knees. People might have died because of CrowdStrike.
CrowdStrike happened because one of the "user-empowering" features: ability to install kernel drivers on a machine. Now, people are begging Microsoft to adopt a more isolated, user-mode-only device driver system, so this kind of incident won't happen. Yes, some users who want to install their precious kernel driver could have problems, but at least the world would keep running.
Microsoft is nowhere to be blamed about this. Secure defaults is the responsibility of every product that intends to be used at scale.
If you'd like, you can disable Secure Boot, keep your data in plaintext on your hard drive, let all applications run as root, and you'd be the most powerful user in the universe. I'm all for personal freedom to disable the security features, but, at scale defaults must always prefer security over capability. That's not about Microsoft, or Google, or Apple. That's about at scale risk management.
people are begging Microsoft to adopt a more isolated, user-mode-only device driver system, so this kind of incident won't happen
Those people are, to put it bluntly, either authoritarian idiots or corporate shills. They want to give more control to Microsoft, but it's not like M$ is all that competent either, as what this article and past fiascos (like the Blaster you mentioned) have already shown, so they're going to just make things worse for everyone.
CrowdStrike happened because one of the "user-empowering" features: ability to install kernel drivers on a machine.
And crimes happen because people still have freedom. Doesn't mean we should start imprisoning (or enslaving to the machine) everyone from birth.
"Freedom is not worth having if it does not include the freedom to make mistakes."
All security bugs are result of incompetence. Massive DoS incidents are result of scale. Use your magic wand, bring Linux to 90% desktop OS marketshare, and see how one malware destroys an order of magnitude more Linux devices than Windows.
> They want to give more control to Microsoft
No, they want secure defaults, not less control.
> And crimes happen because people still have freedom.
Okay, let me extend that whataboutism with "hey why do we have laws that limit people's freedom, let's remove all the laws if people are entitled to infinite freedom, and can be trusted with their judgement".
> Freedom to make mistakes
Not at the expense of harming others.
Can you show me the law that deputizes Microsoft to be judge, jury and executioner on other people's private property?
> Not at the expense of harming others.
Isn't that exactly what Microsoft was doing here?
> When you have a billion devices running around the world
This is exactly the point: Microsoft does NOT have those billions of devices, their users do.
> CrowdStrike happened because one of the "user-empowering" features: ability to install kernel drivers on a machine.
Crowdstrike happened because the corpration behind it had direct control over the computers it was running on and the ability to install security updates without the user's consent. They even ignored configuration that was supposed to delay updates for critical machines. Spinning this as some kind of failure of user empowerment instead of a consequence of the same kind of ownership inversion that secure boot and other DRM brings is absurd.
> at scale defaults must always prefer security over capability
And that's exactly how you end up in a dystopia. Because the demand for increased security never ands and can be used to justify any and all loss of freedom.
Blaster was a wake-up call, caused DDoS on servers, and kickstarted similar variants like SQL Slammer, Sasser, Conficker that hindered many services around the world. Stop dismissing real threats because you haven't personally affected by them.
> This is exactly the point: Microsoft does NOT have those billions of devices, their users do.
Do you prefer a billion unpatched systems roaming around with all ports open and running all programs as admin? Why are you against as secure defaults?
> Because the demand for increased security never ands and can be used to justify any and all loss of freedom.
If you don't like secure defaults, just turn them off. If you don't like how Windows does something, use an alternative. What dystopia are you talking about?
The bug is in the fact that billions of machines are running exactly the same proprietary software.
Following the "virus" metaphor, having billions of identical organisms is how you get pandemics, mass die-offs, and extinctions.
What's the alternative?
* The UEFI Consortium via their spec mandates nothing, but Microsoft (not mentioned here, but to stick Windows stickers on your boxes and get WHQL for your hardware) requires carrying their db keys: https://mjg59.dreamwidth.org/9844.html
* You can take control of the process yourself and evict Microsoft's keys: https://mjg59.dreamwidth.org/16280.html the details are sort of in here, but let me summarize it for you: by default the platform key is provided by your manufacturer, which signs a key-signing-key, which itself signs updates to the DB (what you can boot) and DBX (what won't boot even with valid signatures). As the article says, x86 specifications explicitly require that this database be modifiable, so you can always install your own keys. I did this for a while, and on my laptop I evicted Microsoft's keys entirely. Ultimately you can bypass this if you can bypass the BIOS password simply by resetting the database or disabling secure boot and... well, https://bios-pw.org/ .
* The whole thing was built so that you can re-sign your own kernels and other bits if you want (you could just sign your distribution's db keys with your KEK, which will make OS upgrades smoother): https://mjg59.dreamwidth.org/12368.html
* Here is an article on secure versus restricted boot: https://mjg59.dreamwidth.org/23817.html - I said above that the x86 specifications explicitly allow the key database to be modified (Microsoft's ARM devices were the inverse).
Now some non-Garrett points:
* To be affected by Windows Update, you need to run Windows. Tautological and true!
* If you update your firmware via, say, LVFS (https://fwupd.org/) and your distribution via its standard tools you get updates to things like dbx all the time. All from your hardware vendor and friendly FOSS folk, no Microsoft involved. You might even be using SBAT right now.
* Those Talos II boards people like? They also have secure boot. It is entirely optional and since Microsoft only implemented a "kinda" version of NT for PowerPC, they're definitely not involved. It is not UEFI, since there's no UEFI for POWER (there is for ARM and RISCV though). You also aren't getting anything from LVFS and barely anything from your distro, but, secure boot is there. You can turn it on.
Personally, providing I can control the keys and decide what is and is not trusted and whether I use it, I am fine with it. Depending on what you want to achieve, secure boot is not always unreasonable, and neither are TPMs - small example, software exploits won't be able to successfully modify the boot chain if you have good key management (i.e. you sign elsewhere). They also have their limitations - as usual, physical access is hard to defend against and remote attestation is a hard problem all around.
> Things like TPM and "secure" boot were never envisioned for the interests of the user.
I am successfully using TPM with coreboot and Heads, with my own keys, to protect against boot attacks on my Librem 14 with Qubes OS.
"Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety"
Is the ability to run an insecure bootloader on a system that has an installed OS with a security policy built around it not running insecure bootloaders an essential liberty? Let's say it is, for the sake of argument. Have you given up that freedom? Given that you can disable secure boot, or boot a live image and remove the SBAT entry, or boot an updated image and recover your existing install, I think it's hard to say that you've actually given it up. Is that security temporary? A well-maintained secure boot chain provides you long-term security against a variety of threats, so I don't think it's clearly temporary.
It's fine to disagree, but please don't do so by pretending that a misquote is meaningful.
[0] https://linuxunplugged.com/572
[1] https://fedoramagazine.org/automatically-decrypt-your-disk-u...
[0] https://fedoramagazine.org/use-systemd-cryptenroll-with-fido...
[1] https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-c...
[2] https://docs.redhat.com/en/documentation/red_hat_enterprise_...
- have custom secure boot platform key
- use a unified kernel image (UKI) which means I directly boot the kernel from efi (and place it in the efi partition)
- sign the image with that platform key (I use sbctrl)
- have every thing else including swap partition for hybernation fully disk encrypted, I could set it up to auto unlock using TPM2 but I would recommend using a long password. TPM2+password would be optimal. There had been too many cases of leaky TPMs and especially on a laptop you don't want to fully rely on it (through you in turn could decide to auto login if PCRs are unchanged, or login using only the (often not so secure) fingerprint reader etc.)
- efi password, I mean if you don't set that you lose most secure boot benefits... EDIT: Not really most, there is still a bunch of ways it helps but it's anyway a bad idea to rely on secure boot and not have a efi password
As bonus tip:
- include the vfat in your initramfs (i.e. `MODULES=(vfat)` in `/etc/mkinitcpio.conf`) if your booting kernel and installed kernel modules ever mismatch that is nice to have to fix the issue
keys are just stored on the device, for the typical laptop use-case this is good enough (platform key only used by a single device, no MDA or anything like that)
Personally, I trust LUKS with passphrases far more than I trust some random proprietary hardware implementation nobody can audit...
It's also important to me to be able to recover the disk contents with the passphrase on another machine if the motherboard dies. Maybe that's what you meant (backup passphrase), but I think you meant requiring both?
- I'm only using a long password
- but it would be optimal to require PCR values and password
Note that in any case where you use PCR values you always should setup a secondary way to unlock the partition. Or else you will lose your data if some of your hardware measured into a PCR breaks.
Requiring both is optimal as it 1. doesn't rely on TPM/PCRs but 2. prevent certain attack vectors possible with password only but not possible with PCRs. Through you now also have to manage a backup unlock method. Which is annoying. And the security benefits are negligible/irrelevant for most people. Which is why I don't use it.
Nit: It's useful to distinguish between passwords (checked against a hash for auth) and passphrases (used for decryption). It's an important practical distinction because a lost password can in general be bypassed out-of-band somehow while a backup strategy for passphrases is essential.
Similar prompts for decryption will ask you for passwords in most cases as non technical users shouldn't need to understand the underlying technical differences (nor do they normally want to, or do).
I wonder what went wrong here? If you would read the EFI boot order it would clearly say to boot shim first? Or were these dual boot setups where the user would use the firmware menu to select linux or windows?
Anyway this comes at a time when I want to install linux on my work PC, since it has two nvme slots I think I'll go with installing it on a completely separate drive. Would have not prevented this issue though, which seems a legitimate fix from microsoft, just bad communication.
I suspect the MS installer simply scans the EFI BootXXXX entries and looks for a non-Windows boot-loader path like, for example, /EFI/$distro/shimx64.efi
If one-such doesn't exist the installer likely assumes it is not a dual-boot system.
I can tell you that you are wrong. Whatever the company’s flaws, the people in Windows care deeply about compatibility and about not breaking things with updates. I have hours of stories from the trenches, and could probably talk at length about how such a point of view would be suicidal for the Windows business.
I don’t know what went wrong here, and I’m not saying Microsoft is blameless. I am saying that whatever went wrong was NOT due to lack of caring about breaking things, even non-Microsoft stuff sharing the same computer.
In that sense, I don't see your experience as invalidating the statement "MS has zero vested interest in caring"?
P.S. The ultimate irony of this situation is that it actually ends up breaking concurrent windows installs more often than anything else.
Exceptions with string messages and full stack traces might be yet another underrated Java invention.
Does it help? The stack trace at the point where the dialog box is displayed is useless.
Failed to open configuration file
Caused by:
Failed to open path PATH
Error access deniedI think the only button on the dialog box was "Restart".
Error design needs to be its own subject / specialization. Errors need to say what the problem is and how to fix it, in an ideal world, or what the user can do or should google to solve it.
And of course, any error code of any public software should be listed on a website or a locally accessible resource.
Here's an IBM example, for just a single OS facility: https://www.ibm.com/docs/en/SSLTBW_2.4.0/pdf/hasa100_v2r4.pd...
Or even better, a small library which'd allow bootloader to generate it on the fly.
http://fukuchi.org/works/qrencode/index.html.en
That said, with iPhone cameras supporting live OCR and URL detection, a QR code would be unnecessary.
A URL with specific content is just another thing that now needs to be maintained along with the code and failure modes.
(Realistically I expect that's mainly used for debugging purposes for the Shim authors.)
By leaving the reason vague an attacker has no immediate feedback and no clue how to remedy.
I vastly prefer the way this works now.
It's the HN effect. The pool of geniuses here suggests to the reader that the pool of intelligence outside of this microcosm is similar. It's not.
Criminals are overwhelmingly stupid. It's why LEO catches so many of them. Smart people don't tend to do crime, they tend to sell their skills to more legitimate enterprises.
At least it was easy to turn off. I just wish the error message mentioned Secure Boot -- it took me a few minutes to figure out what was wrong. At first I thought I had a corrupt USB stick or something.
If you are using Nvidia graphics you have to deal with signing the kernel drivers but it is pretty easy, AMD or Intel works out of the box.
I saw someone else give a similar reasoning that if there were a booting error, they would never assume it was a rootkit, but some breakage between all of the booting cruft. I certainly lack any expertise to understand what happens during boot to be able to diagnose problems.
As a user, I see very little benefit to using UEFI.
"We won't accept any reports because your secure boot chain is too short." To put it bluntly and crudely. Not to dismiss a very real and important real-life issue.
I've lost people I love in my life over similar things. I don't want to be in a similar situation in other Walks or Paths of life.
It's a powerful incentive mechanism. Even if you're believed in the end how long did it take? How old? And now that difficult thing becomes a talking point when you just wanted to build.
You can always disable secure boot if you want to, but in this case installing the patches released two years ago would probably be a better fix.
When it comes to the realities of dual-booting, I had tons of problems with Win7/8/10 with suspend-to-hiberfile.sys issues and updates 10 years ago breaking grub. 10 years ago I finally decided, "You know what, I'm just going to run Linux, if I really need Windows or Mac, I can run a VM or use a separate spare computer."
Since then I have successfully setup Secure Boot for my distro, learned how to tweak QEMU for performance and passthrough, got a working QEMU macOS VM (although having to update every few months to keep XCode working is a pain), and generally pretty happy with the state of affairs.
Microsoft is within US-legislation. So a three-letter agency already has the keys and their spyware is a signed UEFI module.
it just screams you have no data hygiene. it's the extra step after living years with 723 open tabs.
qemu passtrhu is the way. and if you don't own expensive hardware (i.e. only integrated graphics like all feasible laptops), just dual boot with your own signing keys so you don't have yo worry about revocation crap. either its signed or not. revocation is just replacing the root PK keys.
Note that it requires a second graphics card to work.
The sad and depressing part is that along the way we lost all possibilities of running coreboot or libreboot as an open alternative.
The only real option is to buy a used laptop from before the T44x generation (if you really want it secure)... or newer machines that come with other perks like soldered-on batteries that destroy the mainboard along with them when they leak out eventually.
I am not sure what the consumer rights protection agencies on the planet are doing, but seemingly they've been asleep at the wheel for way too long now.
> (Tinfoil hat) (...) I think part of the reason MS is enforcing TPM2.0 and now this SBAT update is that there is widespread rootkit level malware and they are trying to stay ahead of the curve.
The only vendors that seem to do something against it are somewhat System76, Frame.Work, Purism and maybe Starlabs. But the huge majority of devices is under the absolute control of Microsoft's signing process now. So I would argue that this isn't a tinfoil conspiracy, but a strategical decision that MS made to re-grab their lost power on x86 systems.
I just wish there would be more free and open options.
The RISC V meme of the Hackers movie from the 90s is now so old that it's never gonna happen anyways. Those CPUs are nice and all, but you're even better off using a Pentium CPU performance wise, and that's a 20 years old CPU.
This is out of date information. Currently purchasable RISC-V CPUs (in e.g. Milk-V Jupiter) are already the level of Intel Core 2, with the important difference that Jupiter has 8x of them, whereas the top Core 2 chips were only quad-core.
Cores expected to ship in early 2025 on 16-core Milk-V Oasis are at the level of Intel Haswell or AMD Zen 1.
Akeana, Tenstorrent, SiFive and Ventana have IP available for licensing which performance is similar or above Apple M1.
There isn't much of a performance gap left to close.
There literally is. BlackLotus bootkit actively abuses a vulnerability Microsoft has been trying to patch (by updating the blacklist the vulnerable bootloaders) for the past two years and it's still ongoing AFAIK.
I see the end of the chain still ends up at "trust" in humans/companies at some level. Microsoft broke dual boot systems because they think they know what's best for someone else's system and that's not okay.
I'd be also really curious to hear how MS was attempting to do dual-boot detection, I hope someone (more skilled than I) would reverse engineer that bit from the update.
Reading into https://www.gnu.org/software/grub/manual/grub/html_node/Secu...
It's possible it's both?
> I'd be also really curious to hear how MS was attempting to do dual-boot detection
I'm in the boat that they shouldn't doing dual boot detection at all, it sounds like everyone agreed to use SBAT to stop vulnerable bootchains from being exploitable and some Linux distributions got caught slacking.
The fact that the list of allowed GRUB versions is itself manageable via a Windows Update points to some other issues with this particular security scheme, given Microsoft’s own recent history of mishandling private keys.
I don't think this is generally true. Since most computers don't ship with Ubuntu's CA directly trusted their signed components rely on a chain of trust that goes up through Microsoft's 3rd party UEFI CA cert to their root. I don't know the specific details of UEFI's implementation but it seems incredibly unlikely that it'd allow a subordinate CA to sign an update that distrusts components upstream of it.
If an OEM does ship Ubuntu's root or if a system owner has manually installed it then sure, but that's not the majority of systems.
Secure Boot Advanced Targeting
* No matter how many times I do the captcha.
(The first obstacle would be that AFAIK the EFI isn't mounted by default on Windows, but I believe it should not be hard to tell Windows to mount it and give it a drive letter.)
It's not the TPM, it's a simple UEFI variable. AFAIK, there's a way in the BIOS to reset all these variables to their original default value, though you might have to use the "clear CMOS" jumper to do it.
So installing Windows can break a computer for Linux.
That's a great antitrust issue. Microsoft should be fined for that.
How dare Microsoft operate within the bounds of an agreed-upon industry standard, what a monopoly!
> those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain
This feels like a "my secure compartments are all connected together" moment. If Microsoft want to verify that they're in an all-Microsoft boot chain, sure, whatever, fine. But somehow the compromise of any loader allows compromise of Windows? And in turn Microsoft are able to break grub installations? Why is that acceptable?
(also, I feel a bit "I told you so" about this. Back when all this was being introduced I felt that (a) secure boot increases the risk of locking you out of your machine and/or data loss and (b) a situation where Linux is dependent on the collaboration of Microsoft in order to boot is very dangerous long-term.)
Exactly how would you propose starting software securely from an unknown environment?
> Back when all this was being introduced I felt that (a) secure boot increases the risk of locking you out of your machine and/or data loss
So does a password and encryption.
Accept that it’s impossible?
In this scenario, people who are ready to give up can simply stop updating their software, which will solve their issue. YMMV of course.
A 5 cent hardware button which gives you a small time windows to install a new trusted bootloader could achieve the same thing without trusting microsoft.
Having to send someone out to press the button at a thousand desks in order to update the bootloader? Also not appealing.
This is vaguely the experience that should have been present in an Empowered User centric BIOS.
First cold boot; BIOS verifies the hardware isn't broken, checks for a boot preference, finds none.
Present the User with a set of choices: Check for BIOS Updates (manufacturer), Check for OS Choices (manufacturer), Begin installing an OS (options list). Locally cached (present with the system) choices would be listed first. Microsoft Windows (installer) is probably OEM shipped (might not be). Linux / DistroName plugged in USB device, etc... 'Local Network boot (search)', and 'Install from the Internet' (shipped by manufacturer or added by local preference).
The BIOS would also support enrolling ANY signing keys of local preference with user confirmation. This should happen even at first boot for the keys known by the manufacturer; they shouldn't just be in there for free, confirming the key with the user should be part of the flow.
The BIOS _MUST_ also support multiple bootable entries, even if one is the default (without a timeout, even with only manual selection E.G. F12 / F11 / whatever... though this too should be standardized).
The point of personal computers is to make _personal_ computing easy. Everything else can just be an add on.
And how would you call the System code that does this? Would you want such a piece of code to be able to Output something to the screen in case it can't find such a boot sector? Should it be able to take user Input (e.g. in case multiple valid boot sectors are found)? These are quite Basic requirements for any early-boot phase.
You can buy a computer with Linux installed, today!
Ubuntu is easy, so is kubuntu.
You can do anything on Linux that you can do on windows and most of the time it's child's play. The past is the past, give up on windows.
Now I always google around a bit before applying any fresh Windows updates to see of there's any breakage reported.
for personal use, not really worth it imo
if you're installing the right version of windows (Enterprise ltsc) it's already one click install. and your applications will change every week anyway.
I'm sure it's all based on silent install or the /s switch for install.bat. If my memory is working.
I had to switch to Linux just to get a machine I could rely on.
Ive never been sucessfully able to dual boot windows and linux on a mobo with secure boot turned on, it seems that is a feature not a bug I'm sure MS would never influence hardware vendors to make it dissadvantage a growing number of linux users.
the only time it's worth the hassle for we to enable it: travel to the USA, Russia and most of africa (if the country have USA backed airport security, like uganda). pause updates, enable secure boot with a disposable key we don't store anywhere. that on top of the usual FDE with plausible deniability dual boot.
but we still prefer to just fly contributors with blank devices if we can.
If you use full disk encryption secure boot is pretty essential, otherwise an attacker can modify the code that asks for your credentials to also log them somewhere easily accessible, circumventing your entire encryption. If you don't do full disk encryption it's still a decent protection against some bootkits.
It can absolutely be more trouble than it's worth. It's not that useful in most desktop computers. But if you are traveling with a laptop it's probably worth some effort to keep secure boot working on that system (and make it more difficult to disable)
Once I am behind the border, I am reinstalling the system with encryption, then proceed to download key material and other important stuff from home over the internet.
I am never letting anyone near my unlocked laptop and if I ever find it turned off e.g. while visiting office toilet, I just assume it has been infected with firmware level rootkit and I am wiping it without decrypting.
If it's removed from my sight during the border check, I assume the same, purchase a new one in a brick-and-mortar shop and sell the infected one when I am back home.
In what threat model? If the attacker has access to your PC they can just as well install a physical keylogger intercepting the signals from the keyboard.
The main use case for disk encryption is preventing data loss when the device is stolen. That's a realistic threat that people face, not boogeyment coming into your house and replacing your bootloader with a malicious one.
I have similar doubts on whether my system is significantly more secure as a result of using it.
Based. Unfathomably based.
i'll probably read the test, but that's some high quality posting from the get-go!
https://www.sportskeeda.com/pop-culture/who-hudson-mohawke-d...