Hacker News Reader

Comment by ab71e5 | Hacker News Reader

> Microsoft's stated intention was that Windows Update would only apply the SBAT update to systems that were Windows-only, and any dual-boot setups would instead be left vulnerable to attack until the installed distro updated its grub and shipped an SBAT update itself.

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.

View on HN

From the people reporting this affecting their Linux boots in various IRC/Matrix forums and my diagnostics with them, very often they weren't dual-booting in the Microsoft sense, in that they were booting using the UEFI Removable Media Path so there was no entry in the motherboard firmware's Boot menu.

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.

MS has zero vested interest in caring. If they brake booting for Linux users, how does that hurt them in any meaningful way? Sure they get some press, but is it bad press if most people are never affected by this?

It makes Linux more robust. Since Microsoft is the king of vulnerability, making Linux more robust is NOT in their best interest. I actually think Microsoft did a GOOD THING. This should create a mad scramble to tighten up security at all those lackadaisical distros!

I worked for Microsoft for 17 years, most of that in and around Windows.

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.

I think there's a distinction between individuals caring and the corporate ("more than the sum" of individuals comprising it) caring.

In that sense, I don't see your experience as invalidating the statement "MS has zero vested interest in caring"?

Is that the same company whose CEO said Linux was a cancer?

Microsoft's bootloader is clearly intended to be a pain in the ass. There is nothing new about this situation. They have been doing it since the 90s when any windows update would write over your MBR without a care in the world. We all hoped that UEFI boot menus would resolve the situation. They would have, if only Microsoft were willing to stop intentionally polluting everyone's partitions. Instead, it is not only the default, but the only option, for the windows installer to squat in the first EFI System Partition it sees. That means that if you install linux first and windows second, windows will install its bootloader to your ESP. Even if it's too small. There is no way to disable this behavior. It's asinine.

P.S. The ultimate irony of this situation is that it actually ends up breaking concurrent windows installs more often than anything else.

People that dualboot are probably also people that run random debloat scripts that disable telemetry. So when such system broke there was no signal it happened.

Doubtful. I don't.

Reply on news.ycombinator.com